Today AWS is launching a new feature for AWS Certificate Manager (ACM), Private Certificate Authority (CA). This new service allows ACM to act as a private subordinate CA. Previously, if a customer wanted to use private certificates, they needed specialized infrastructure and security expertise that could be expensive to maintain and operate. ACM Private CA builds on ACM’s existing certificate capabilities to help you easily and securely manage the lifecycle of your private certificates with pay as you go pricing. This enables developers to provision certificates in just a few simple API calls while administrators have a central CA management console and fine grained access control through granular IAM policies. ACM Private CA keys are stored securely in AWS managed hardware security modules (HSMs) that adhere to FIPS 140-2 Level 3 security standards. ACM Private CA automatically maintains certificate revocation lists (CRLs) in Amazon Simple Storage Service (S3) and lets administrators generate audit reports of certificate creation with the API or console. This service is packed full of features so let’s jump in and provision a CA.
Provisioning a Private Certificate Authority (CA)
First, navigate to the ACM console in a region and select the new Private CAs section in the sidebar. From there click Get Started to start the CA wizard. For now, you only have the option to provision a subordinate CA so we’ll select that and use super secure desktop as the root CA and click Next. This isn’t what you would do in a production setting but it will work for testing out our private CA.
Now, configure the CA with some common details. The most important thing here is the Common Name which it set as secure.internal to represent my internal domain.
Now we need to choose a key algorithm. Elliptic Curve Digital Signature (ECDSA) is the new kid on the block and makes for much smaller key sizes but isn’t quite as performance friendly or compatible as the old standby RSA. You should choose the best algorithm for your needs but know that ACM has a limitation today that it can only manage certificates that chain up to to RSA CAs. For now, go with RSA 2048 bit and click Next.
In this next screen, you are able to configure my certificate revocation list (CRL). CRLs are essential for notifying clients in the case that a certificate has been compromised before certificate expiration. ACM will maintain the revocation list for me and I have the option of routing my S3 bucket to a custome domain. In this case you’ll create a new S3 bucket to store my CRL in and click Next.
Finally, review all the details to make sure you didn’t make any typos and click Confirm and create.
A few seconds later and you are greeted with a fancy screen saying I successfully provisioned a certificate authority. You still need to activate my CA by creating a certificate signing request (CSR) and signing that with a root CA. Click Get started to begin that process.
Now copy the CSR or download it to a server or desktop that has access to my root CA (or potentially another subordinate – so long as it chains to a trusted root for clients).
Now use a tool like openssl to sign my cert and generate the certificate chain.
$openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in csr/CSR.pem -out certs/subordinate_cert.pem
Using configuration from openssl_root.cnf
Enter pass phrase for /Users/randhunt/dev/amzn/ca/private/root_private_key.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
stateOrProvinceName :ASN.1 12:'Washington'
localityName :ASN.1 12:'Seattle'
organizationName :ASN.1 12:'Amazon'
organizationalUnitName:ASN.1 12:'Engineering'
commonName :ASN.1 12:'secure.internal'
Certificate is to be certified until Mar 31 06:05:30 2028 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
After that copy subordinate_cert.pem and certificate chain back into the console. and click Next.
Finally, review all the information and click Confirm and import. You should see a screen like the one below that shows my CA has been activated successfully.
Now that you have a private CA we can provision private certificates by hopping back to the ACM console and creating a new certificate. After clicking create a new certificate select the radio button Request a private certificate then click Request a certificate.
From there it’s just similar to provisioning a normal certificate in ACM.
Now you have a private certificate that you can bind to my ELBs, CloudFront Distributions, API Gateways, and more. You can also export the certificate for use on embedded devices or outside of ACM managed environments.
–Author: Randall