Amazon Certificate Manager Private Certificate Authority

In the course “Security Engineering on AWS” there are 3 slides on ACM Private CA.

From the courseware:

ACM Private Certificate Authority (CA) is a managed private CA service that helps you easily and securely manage the lifecycle of your private certificates. ACM Private CA provides you a highly-available private CA service without the upfront investment and on-going maintenance costs of operating your own private CA. ACM Private CA extends ACM’s certificate management capabilities to private certificates, enabling you to manage public and private certificates centrally and have ACM renew your private certificates automatically on your behalf. You also have the flexibility to create private certificates for applications that require custom certificate lifetimes or resource names. With ACM Private CA, you can create and manage private certificates for your connected resources in one place with a secure, pay as you go, managed private CA service.

To expand on the slide

  1. The CA Admin uses the Private CA service to create a CA that is subordinate to an existing on-premises company CA.
  2. The subordinate CA certificate is signed by the existing on-premises company CA
  3. The signed certificate is imported back into the Private CA

At the time of the courseware and above slide, the Private CA could only be used with an existing company root or intermediate CA. The idea is that this existing CA is trusted by the end entities, for example browsers, on company managed clients and devices.

However, since the course slide above, in 2019, Private CA now supports the creation of a root CA. There is no need for an external CA.

That allows you to create a highly available CA hierarchy without maintaining the infrastructure.

As usual, I wanted to create a simple demo or walkthrough.

I will create a Root CA. Then a Subordinate CA, which will have a certificate signed by the root. The benefit of a hierarchy like this is that it gives you the flexiblity to restrict access to the root CA, with more permissive access to the subordinate CAs which will issue certificates in bulk. We may also want to delegate sub CAs for different applications, for example one to issue certificates for servers and another for IOT devices, and they might have different admins. Also, auditing and alarms can then be specific to the CA, for example we might want alarms when the root CA issues a certificate.

The prerequisite knowledge for this walkthough is of EC2 and ALB.

To setup a scenario for testing:

I created an EC2 instance with a web server displaying a “Hello World” page.

I created a target group “mytg” with the single instance registered with it.

I created an ALB “myalb” with a standard HTTP listener, and tested it by pasting the DNS name of the ALB into a browser.

To create a Root CA:

Go to Certificate Manager, Private CAs, Get Started.

Select “Root CA”

Configure the CA Name as follows

Organisation: myorg (or whatever you want)

Common Name: myorg root CA (or whatever you want)

Take all the defaults clicking “Next” until the message “Your Certificate Authority was created successfully. Install a CA certificate to activate your CA”. Press Get Started, next, confirm and install.

You should see that the root CA is now active.

To create the subordinate CA:

Go to Certificate Manager, Private CA, Create CA, Subordinate CA.

Organization: myorg

Common Name: myorg subordinate CA

Take all the defaults to finish, confirm and create.

On the success prompt, “Install a CA certificate to activate your CA”, click to get started.

Select ACM private CA to choose the parent CA, select the parent CA from a drop down menu (there will be only one, but what you see in the drop down is its ARN). Once selected, it displays the parent CA type of “root” and its common name.

Note the path length of 0, with choices 0-4. Leave this at 0, which means that this CA will issue certificates directly to end entities rather than to other CAs. Click generate.

Now in the console we see the subordinate CA is active.

To request a certificate:

Go to Certificate Manager, request a certificate, request a private certificate, select the subordinate CA from a drop down list.

Choose a domain name. I used You can replace this with whatever you want.

In the console we see the certificate is issued but “In use” is “No”.

Now to associate the certificate with the ALB:

Go to the ALB, listeners tab, add listener, HTTPS, add action, forward to, you will see a drop down list of target groups, mine was called “mytg”.

Because we are using HTTPS we have to choose a certificate. In “Default SSL Certificate” choose the certificate from a drop down list. Click Save.

Go to Certificate Manager to see the “In use” change to “Yes”

Ensure that the Security Group associated with the ALB allows port 443.

At this point you could paste the DNS name of the ALB into a browser tab and prefix “https://” to see browser warnings and the certificate details. You should see that the certificate is not trusted. The error or warning message depends on the browser.

In order for your device to trust the certificate, it needs to trust the Root CA:

In Certificate Manager, Private CAs, Select the Root cert, Action, Export CA Certificate, select “Export certificate body to file” to download the certificate to your client device. It is a PEM file called “certificate.pem”

In the browser, import the certificate into the browsers certificate store. How this is done depends on the browser. In Chrome, its under settings, advanced, Privacy and Security, Manage Certificates and the certificate ends up in the list of Trusted Root CAs.

Now repeat the test of browsing to the ALB. This time the certificate should be trusted but there will still be a warning. This is because the DNS name of the ALB does not match the common name in the certificate.

You could leave it there for this test. In my test, I already have a Route 53 public hosted zone and a registered domain, so I created an ALIAS record mapping to the DNS name of the ALB.

Then browsing to worked without warnings.

To clean up, as there is a monthly cost for Private CA.

Delete the ALB.

Delete the certificate that was used for the ALB listener

Disable and delete the Sub CA and Root CA