With AWS Certificate Manager Private Certificate Authority (ACM Private CA) it is possible to create private certificate authority (CA) hierarchies, including root and subordinate CAs, minus the maintenance and investment costs of operating an on-premises CA.

        <p>In this article, I will explain ways to use ACM Private CA with <a href="https://aws.amazon.com/cloudhsm/" target="_blank" rel="noopener noreferrer">AWS CloudHSM</a> to use a hybrid public key infrastructure (PKI) where the root CA is in CloudHSM, and the subordinate CAs come in ACM Private CA. In this configuration your root CA is <em>portable</em>, and therefore it could be securely moved outside the AWS Region where it had been created.</p> 

Important: This post assumes that you will be familiar with the essential ideas of CA trust and hierarchy. The example in this article uses a sophisticated hybrid configuration for operating PKI.

The Challenge

The main CA private key of one’s CA hierarchy represents the anchor of trust for several CAs and end entities that use certificates from that hierarchy. A root CA private key generated by ACM Private CA can’t be transferred or exported to some other party. You might require the flexibleness to move control of one’s root CA in the foreseeable future. Situations where you might move control of a root CA include cases like a divestiture of a corporate division or perhaps a major corporate reorganization. In this article, I’ll describe one solution for a hybrid PKI architecture which allows you to make use of the option of ACM Private CA for certificate issuance, while maintaining the flexibleness provided by having direct portability and control of one’s root CA key. The perfect solution is I detail in this article uses CloudHSM to make a root CA key that’s predominantly kept inactive, plus a signed subordinate CA that’s created and managed online in ACM Private CA which you can use for regular issuing of further subordinate or end-entity certificates. Within the next section, You’re showed by me ways to achieve this.

The hybrid ACM Private CloudHSM and CA solution

With AWS CloudHSM, it is possible to create and use your personal encryption keys that use FIPS 140-2 Level 3 validated HSMs. CloudHSM gives you the flexibleness to integrate together with your applications through the use of standard APIs, such as for example PKCS#11. Most importantly because of this solution is that CloudHSM supplies a suite of standards-compliant SDKs for you yourself to create, export, and import keys. This may make it possible for one to securely exchange your keys with other commercially-available HSMs, as as your configurations allow it long.”

Through the use of AWS CloudHSM to store and perform cryptographic operations with root CA private key, and through the use of ACM Private CA to control a first-level subordinate CA key, you keep up a completely cloud-based infrastructure while still retaining usage of – and control over – your root CA key pairs. It is possible to keep the key couple of the main in CloudHSM, where in fact the ability is had by one to escrow the keys, and only generate and use subordinate CAs in ACM Private CA. Figure 1 shows the high-level architecture of the solution.

Note: The answer in this article creates the main CA and Subordinate CA 0a but will not demonstrate the steps to utilize Subordinate CA 0a to issue the rest of the main element hierarchy that’s depicted in Figure 1.

This architecture uses root CA that you create and manage with AWS CloudHSM. The main CA is generally necessary for use in the next circumstances:

1. Once the PKI is established by you.
2. If you want to displace a root CA.
3. If you want to configure a certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP).

An individual direct subordinate intermediate CA is managed and made up of AWS ACM Private CA, which I shall make reference to as the primary subordinate CA, (Subordinate CA 0a in Figure 1). A certificate signing request (CSR) because of this primary subordinate CA is then provided to the CloudHSM root CA, and the signed certificate and certificate chain is imported to ACM Private CA then. The principal subordinate CA in ACM Private CA is issued with exactly the same validity duration because the CloudHSM root CA and in day-to-day practice plays the role of a root CA, acting because the single issuer of additional subordinate CAs. These second-level subordinate CAs (Subordinate CA 0b, Subordinate CA 1b, and Subordinate CA 2b in Figure 1) should be issued with a shorter validity period compared to the root CA or the principal subordinate CA, and could be utilized as typical subordinate CAs issuing end-entity certificates or further subordinate CAs as appropriate.

The main CA private key that’s stored in CloudHSM could be exported to other commercially-available HSMs by way of a secure key export process if required, or could be taken offline. The CloudHSM cluster can down be shut, and the main CA private key could be retained in a CloudHSM backup securely. When the root CA can be used, a CloudHSM cluster could be provisioned on demand, and the backup temporarily restored.

Prerequisites

To check out this walkthrough, you must have the following set up:

Process

In this article, you’ll create an ACM Private CA subordinate CA that’s chained to a root CA that’s created and managed with AWS CloudHSM. The high-level steps are the following:

1. Develop a root CA with AWS CloudHSM
2. Develop a subordinate CA in ACM Private CA
3. Sign your subordinate CA together with your root CA
4. Import the signed subordinate CA certificate in ACM Private CA
5. Remove any unused CloudHSM resources to lessen cost

To make a root CA with AWS CloudHSM

1. 1. To set up the AWS CloudHSM dynamic engine for OpenSSL on Amazon Linux 2, open a terminal on your own Amazon Linux 2 EC2 instance and enter the next commands:

      wget https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/EL7/cloudhsm-client-dyn-latest.el7.x86_64.rpm
           

      yum install -y sudo ./cloudhsm-client-dyn-latest.el7.x86_64.rpm

               <li>To create an environment variable which has your CU credentials, enter the next command, replacing <em><span><span>USER</span></span></em> and <em><span><span>PASSWORD</span></span></em> with your personal information: 
       <div class="hide-language"> 
        <pre><code class="lang-text">Export n3fips_password=<em><span><span>USER</span></span></em>:<em><span><span>PASSWORD</span></span></em>
       

       

   2. To generate an exclusive key utilizing the AWS CloudHSM dynamic engine for OpenSSL, enter the next command:

           openssl genrsa -engine cloudhsm -out Root_CA_FAKE_PEM.key
       

      Note : This technique exports a fake PEM private key from the HSM and saves it to a file. A reference is contained by this file to the private key that’s stored on the HSM; it doesn’t support the actual private key. You should use this fake PEM private key file and the AWS CloudHSM engine for OpenSSL to execute CA operations utilizing the referenced private key within the HSM.

   3. To create a CSR for the certificate utilizing the AWS CloudHSM dynamic engine for OpenSSL, enter the next command:

           openssl req -engine cloudhsm -new -key Root_CA_FAKE_PEM.key -out Root_CA.csr
       

   4. When prompted, enter your values for Country Name, Province or state Name, Locality Name, Organization Name, Organizational Unit Name, and Common Name. For the purposes of the walkthrough, it is possible to blank leave another fields.Figure 2 shows a good example consequence of running the command.
      

      Figure 2: A good example certificate signing obtain your private key using AWS CloudHSM dynamic engine for OpenSSL

   5. To sign your root CA using its own private key utilizing the AWS CloudHSM dynamic engine for OpenSSL, enter the next command:

           openssl x509 -engine cloudhsm -req -days 3650 -in Root_CA.csr -signkey Root_CA_FAKE_PEM.key -out Root_CA.crt
       

        <h3>To make a subordinate CA in ACM Private CA</h3> 

1. 1. To make a CA configuration apply for your subordinate CA, open a terminal on your own Amazon Linux 2 EC2 instance and enter the next command. Replace each user input placeholder with your personal information.

      cat ‘
           

      “KeyAlgorithm”:”RSA_2048″,
      “SigningAlgorithm”:”SHA256WITHRSA”,
      “Subject”:
      “Country”:” US ”
      “Organization”:” Example Corp “,
      “OrganizastionalUnit”:” Sales “,
      “State”:” WA “,
      “Locality”:” Seattle “,
      “CommonName”:” www.example.com ”

      ’ > ca_config.txt

develop a sample subordinate CA

 

• To, enter the next command:

   

       aws acm-pca create-certificate-authority --certificate-authority-configuration file://ca_config.txt --certificate-authority-type "SUBORDINATE" --tags Key=Name,Value=MyPrivateSubordinateCA
       

   

  Figure 3 shows an example successful result of the command.

   

  

  Figure 3: An example response from the acm-pca create-certificate-authority command.

   

 

 

To find out more about how to make a CA in ACM Private CA and extra configuration options, see Procedures for Developing a CA in the ACM Private CA User Guide, and the acm-pca create-certificate-authority command in the AWS CLI Command Reference.

 

To sign the subordinate CA with the main CA

 

 

• To retrieve the certificate signing request (CSR) for the subordinate CA, open a terminal on your own Amazon Linux 2 EC2 instance and enter the next command. Replace each user input placeholder with your personal information.

   

       aws acm-pca get-certificate-authority-csr --certificate-authority-arn arn:aws:acm-pca:                              region                              :                              account                              :certificate-authority/                              12345678-1234-1234-1234-123456789012 > IntermediateCA.csr                         
       

   

 

 

 

• For demonstration purposes, it is possible to develop a sample CA config file by entering the next command:

   

       cat > ext.conf << EOF
  subjectKeyIdentifier = hash
  authorityKeyIdentifier = keyid,issuer
  basicConstraints = critical, CA:true
  keyUsage = critical, digitalSignature, cRLSign, keyCertSign
  EOF
       

   

  If you are ready to implement the answer in this post, you need to develop a root CA configuration apply for signing the CSR for the subordinate CA. Information on your X.509 infrastructure, and the CA hierarchy within it, are beyond the scope of the post.

 

 

 

• To sign the CSR for the subordinate CA utilizing the sample minimalist CA application OpenSSL-CA , enter the next command:

   

       openssl x509 -engine cloudhsm -extfile ext.conf -req -in IntermediateCA.csr -CA Root_CA.crt -CAkey Root_CA_FAKE_PEM.key -CAcreateserial -days 3650 -sha256 -out IntermediateCA.crt
       

   

 

 

Importing your signed Subordinate CA Certificate

 

 

• To import the private CA certificate into ACM Private CA, open a terminal on your own Amazon Linux 2 EC2 instance and enter the next command. Replace each user input placeholder with your personal information.

   

       aws acm-pca import-certificate-authority-certificate --certificate-authority-arn arn:aws:acm-pca:                              region                              :                              account                              :certificate-authority/                              1234678-1234-1234-123456789012                               --certificate file://IntermediateCA.crt --certificate-chain file://Root_CA.crt
       

   

 

 

Shutting down CloudHSM resources

 

Once you import your subordinate CA, it really is available for used in ACM Private CA. It is possible to configure the subordinate CA with exactly the same validity period because the root CA, to enable you to automate CA certificate management using and renewals using ACM without requiring regular usage of the main CA. Typically you’ll create a number of intermediate issuing CAs with a shorter lifetime that chain around the subordinate CA.

 

When you have enabled CRL or OCSP for the CA, you need to maintain your CloudHSM within an active state to be able to access the main CA private key for these functions. However, when you have no immediate have to access the main CA it is possible to safely take away the CloudHSM resources while preserving your AWS CloudHSM cluster’s users, policies, and keys within an CloudHSM cluster backup stored encrypted in Amazon Simple Storage Service (Amazon S3).

 

To eliminate the CloudHSM resources

 

 

• (Optional) In the event that you don’t know the ID of the cluster which has the HSM that you will be deleting, or your HSM Ip, open a terminal on your own Amazon Linux 2 EC2 instance and enter the describe-clusters command to get them.

 

 

 

• Enter the next command, replacing cluster ID with the ID of the cluster which has the HSM that you will be deleting, and replacing HSM Ip together with your HSM Ip .

   

       aws cloudhsmv2 delete-hsm --cluster-id                               cluster ID                               --eni-ip                               HSM Ip                         
       

   

 

 

To disable expiration of one’s generated CloudHSM backup

 

 

• (Optional) In the event that you don’t know the worthiness for the backup ID, open a terminal on your own Amazon Linux 2 EC2 instance and enter the describe-backups command to get it.

 

 

 

• Enter the next command, replacing backup ID with the ID of the backup for the cluster.

   

       aws cloudhsmv2 modify-backup-attributes --backup-id                               backup ID                               --never-expires
       

   

 

 

Later, once you do have to access your root CA private type in a CloudHSM, develop a new HSM in exactly the same cluster, which action will restore the backup you made up of the delete HSM operation previously.

 

Depending on your unique needs, you may even desire to securely export a copy of the main CA private key to an offsite HSM through the use of key wrapping. You may want to do this for you personally for managing the CA using another HSM or you might copy a cluster backup to a new AWS Region for disaster recovery purposes.

 

Summary

 

In this article, I explained a procedure for establishing a PKI infrastructure using Amazon Certificate Manager Private Certificate Authority (ACM Private CA) with portable root CA private keys created and managed with AWS CloudHSM. This process lets you meet specific requirements for root CA portability that can’t be met by ACM Private CA alone. Before adopting this process in production, you need to carefully consider whether a portable root CA is really a requirement of your use case, and review the ACM Private CA guide for Planning for a Private CA .

 

When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, take up a new thread on the AWS Certificate Manager forum or contact AWS Support .

 

Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter .