Overview Step 1. Get the cluster CSR Step 2. Create a private key for your Root CA Step 3. Sign the CSR Step 4. Initialize the cluster

Initialize the cluster in AWS CloudHSM

After you create your cluster and add your hardware security module (HSM) in AWS CloudHSM, you can initialize the cluster. Complete the steps in the following topics to initialize your cluster.

Note

Before you initialize the cluster, review the process by which you can verify the identity and authenticity of the HSMs. This process is optional and works only until a cluster is initialized. After the cluster is initialized, you cannot use this process to get your certificates or verify the HSMs.

Topics

Overview
Step 1. Get the cluster CSR
Step 2. Create a private key for your Root CA
Step 3. Sign the CSR
Step 4. Initialize the cluster

Overview

The cluster initialization process establishes your ownership and control over the cluster and your HSMs through a certificate-based authentication system. This process cryptographically proves that you are the sole owner of the HSMs in your cluster and creates the foundation of trust that will be required for all future connections to your HSMs.

This page will show you how to do the following:

Retrieve your cluster's certificate signing request (CSR).
Generate and use the private key(s) to create a self-signed root certificate or a certificate chain.
Sign your cluster's CSR to produce a signed HSM certificate.
Initialize your cluster using the signed HSM certificate and self-signed certificate or certificate chain.

When you're ready to get started, go to Step 1. Get the cluster CSR.

Step 1. Get the cluster CSR

Before you can initialize the cluster, you must download and sign a certificate signing request (CSR) that is generated by the cluster's first HSM. If you followed the steps to verify the identity of your cluster's HSM, you already have the CSR and you can sign it. Otherwise, get the CSR now by using the AWS CloudHSM console, the AWS Command Line Interface (AWS CLI), or the AWS CloudHSM API.

Step 2. Create a private key for your Root CA

Note

For a production cluster, the key you are about to create should be created in a secure manner using a trusted source of randomness. We recommend that you use a secured offsite and offline HSM or the equivalent. Store the key safely. The key establishes the identity of the cluster and your sole control over the HSMs it contains.

For development and testing, you can use any convenient tool (such as OpenSSL) to create and sign the cluster certificate. The following example shows you how to create a key. After you have used the key to create a self-signed certificate (see below), you should store it in a safe manner. To sign into your AWS CloudHSM instance, the certificate must be present, but the private key does not.

The table below outlines the supported algorithms, key sizes, and curves for certificate generation.

Algorithms	Size/Curves
RSA PKCSv1.5	2048, 3072, 4096
RSA-PSS	2048, 3072, 4096
ECDSA	prime256v1, secp384r1, secp521r1
Digest	SHA-224, SHA-256, SHA-384, and SHA-512

Use the following example command to create a private key for your self-signed Root CA.


$ openssl genrsa -aes256 -out customerRootCA.key 2048
Generating RSA private key, 2048 bit long modulus
........+++
............+++
e is 65537 (0x10001)
Enter pass phrase for customerRootCA.key:
Verifying - Enter pass phrase for customerRootCA.key:

Step 3. Sign the CSR

In the previous steps, you retrieved your cluster's CSR and created a private key for your root CA. In this step, you will use your private key to generate a signing certificate in order to sign your cluster's CSR. The topics below will guide you through the process of creating a single self-signed certificate, or a certificate chain, using OpenSSL. You do not need the AWS CLI for this step, and the shell does not need to be associated with your AWS account.

Important

To initialize your cluster, your trust anchor must comply with RFC 5280 and meet the following requirements:

If using X509v3 extensions, the X509v3 Basic Constraints extension must be present.
The trust anchor must be a self-signed certificate.
Extension values must not conflict with each other.

Choose one of the following approaches to sign your cluster's CSR:

Choose your certificate approach

You must choose one of the following two approaches. Do not complete both approaches.

Option A: Single self-signed certificate

Create a single self-signed root certificate to sign your cluster's CSR. This is the most simple, direct method of establishing trust.

Recommended for:

Environments where an external PKI is not required
Test and development environments where simplicity is preferred

Go to: Create a single self-signed certificate

Option B: Certificate chain with intermediate CA

Create a certificate chain using an intermediate certificate authority. An intermediate certificate chain provides enhanced security, scalability, and flexibility by allowing root Certificate Authorities (CAs) to remain offline while delegating certificate issuance to intermediate CAs, thereby reducing the risk of compromising the root CA.

Recommended for:

Environments where an external PKI is required
Integration with AWS Private Certificate Authority (PCA)

AWS PCA Integration Example: You can use AWS Private Certificate Authority to create and manage your intermediate CA certificates. This provides automated certificate lifecycle management, including renewal and revocation, while maintaining the security benefits of keeping your root CA offline. For more information on AWS PCA, see the AWS Private Certificate Authority User Guide.

Go to: Create an intermediate certificate authority (ICA) chain

Create a single self-signed certificate

The trusted hardware that you use to create the private key for your production cluster should also provide a software tool to generate a self-signed certificate using that key. The following example uses OpenSSL and the private key that you created in the previous step to create a self-signed root CA signing certificate. The certificate is valid for 10 years (3652 days). Read the on-screen instructions and follow the prompts.


$ openssl req -new -x509 -days 3652 -key customerRootCA.key -out customerRootCA.crt
Enter pass phrase for customerRootCA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

This command creates a certificate file named customerRootCA.crt. Put this certificate on every host from which you will connect to your AWS CloudHSM cluster. If you give the file a different name or store it in a path other than the root of your host, you should edit your client configuration file accordingly. Use the certificate and the private key you just created to sign the cluster certificate signing request (CSR) in the next step.

Sign the cluster CSR with your self-signed Root CA

The trusted hardware that you use to create your private key for your production cluster should also provide a tool to sign the CSR using that key. The following example uses OpenSSL to sign the cluster's CSR. The example command below signs the CSR with the self-signed customerRootCA.crt


$ openssl x509 -req -days 3652 -in <cluster ID>_ClusterCsr.csr \
		-CA <customerRootCA>.crt \
		-CAkey <customerRootCA>.key \
		-CAcreateserial \
		-out <cluster ID>_CustomerHsmCertificate.crt
Signature ok
subject=/C=US/ST=CA/O=Cavium/OU=N3FIPS/L=SanJose/CN=HSM:<HSM identifier>:PARTN:<partition number>, for FIPS mode
Getting CA Private Key
Enter pass phrase for <customerRootCA>.key:

This command creates a file named <cluster ID>_CustomerHsmCertificate.crt. Use this file as the signed certificate when you initialize the cluster.

Verify the signed certificate against the root CA (optional):


$ openssl verify -purpose sslserver -CAfile customerRootCA.crt <cluster ID>_CustomerHsmCertificate.crt
<cluster ID>_CustomerHsmCertificate.crt: OK

After producing the signed HSM certificate with your self-signed Root CA, go to Step 4. Initialize the cluster.

Create an intermediate certificate authority (ICA) chain

The following examples will walk you through creating a certificate chain of length 2, consisting of a root Certificate Authority (CA) and an intermediate CA. You'll first create a self-signed root CA certificate, then generate an intermediate CA that is signed by the root CA. Finally, you'll use the intermediate CA to sign your cluster's CSR, creating a complete trust chain from your HSM certificate back to the root CA. This approach provides enhanced security by keeping the root CA offline while using the intermediate CA for day-to-day certificate operations.

Important

To initialize your cluster with a certificate chain, your chain must meet the following requirements:

The chain must be ordered, starting with the Intermediate CA that signs the cluster CSR. In this order, the first ICA should have an issuer that matches the subject of the next ICA in the chain, and so forth.
Only the Root CA should be self-signed, meaning its issuer and subject should be identical.
The chain must consist of no more than 4 certificates (including the Root CA at the end), and the total size of the chain must not exceed 16 kb (kilobytes).
All Certificate Authorities (CAs) should conform to the RFC 5280 guidelines.

This section provides examples for creating an intermediate certificate authority chain using two different approaches: OpenSSL for local certificate generation, and AWS Private Certificate Authority (PCA) for managed certificate services. Choose the approach that best fits your environment and security requirements.

Note

The following examples are general use case and are both simplified, using the most basic configuration. For production environments, review additional configuration options and security requirements specific to your use case.

OpenSSL

Create OpenSSL configuration file with common v3 extensions for CA:


$ cat > ca-extensions.conf <<EOF
[req]
distinguished_name = req_distinguished_name
[req_distinguished_name]
C = Country Name (2 letter code)
ST = State or Province Name (full name)
L = Locality Name (eg, city)
O = Organization Name (eg, company)
OU = Organizational Unit Name (eg, section)
CN = Common Name (e.g. server FQDN or YOUR name)
[v3_ca]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign, digitalSignature
EOF

Generate a self-signed Root CA using OpenSSL:


$ openssl req -new -x509 -days 3652 -key customerRootCA.key -out customerRootCA.crt -extensions v3_ca -config ca-extensions.conf
Enter pass phrase for customerRootCA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Generate an Intermediate CA key:


$ openssl genrsa -aes256 -out intermediateCA.key 2048
Generating RSA private key, 2048 bit long modulus
........+++
............+++
e is 65537 (0x10001)
Enter pass phrase for intermediateCA.key:
Verifying - Enter pass phrase for intermediateCA.key:

Create the Intermediate CA certificate signing request (CSR):


$ openssl req -new -key intermediateCA.key -out intermediateCA.csr
Enter pass phrase for intermediateCA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Using the self-signed Root CA, create the Intermediate CA certificate:


$ openssl x509 -req -in intermediateCA.csr \
		-CA customerRootCA.crt \
		-CAkey customerRootCA.key \
		-CAcreateserial \
		-days 3652 \
		-extensions v3_ca \
		-extfile ca-extensions.conf \
		-out intermediateCA.crt

Certificate request self-signature ok
subject=C= , ST= , L= , O= , OU=

Combine the certificates into a chain file:


$ cat intermediateCA.crt customerRootCA.crt > chainCA.crt

-----BEGIN CERTIFICATE-----
[Intermediate CA]
-----END CERTIFICATE-----
...
...
-----BEGIN CERTIFICATE-----
[Root CA]
-----END CERTIFICATE-----

Sign the cluster CSR with your intermediate CA:


$ openssl x509 -req -days 3652 -in <cluster ID>_ClusterCsr.csr \
			-CA intermediateCA.crt \
			-CAkey intermediateCA.key \
			-CAcreateserial \
			-out <cluster ID>_CustomerHsmCertificate.crt
Signature ok
subject=/C=US/ST=CA/O=Cavium/OU=N3FIPS/L=SanJose/CN=HSM:<HSM identifier>:PARTN:<partition number>, for FIPS mode
Getting CA Private Key
Enter pass phrase for intermediateCA.key:

AWS PCA

Create and activate a Root CA using AWS Private Certificate Authority:


$ # 1. Create Root CA
aws acm-pca create-certificate-authority \
    --certificate-authority-configuration \
        "KeyAlgorithm=RSA_4096,
        SigningAlgorithm=SHA256WITHRSA,
        Subject={Country=US,Organization=MyOrg,OrganizationalUnit=IT,CommonName=RootCA}" \
    --certificate-authority-type ROOT

# Store the Root CA Authority ARN from the previous output
ROOT_CA_AUTHORITY_ARN="arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<ca-authority-id>"

# 2. Generate Root CA CSR
aws acm-pca get-certificate-authority-csr \
    --certificate-authority-arn $ROOT_CA_AUTHORITY_ARN \
    --output text > customerRootCA.csr

# 3. Self-sign Root CA Certificate
aws acm-pca issue-certificate \
    --certificate-authority-arn $ROOT_CA_AUTHORITY_ARN \
    --csr fileb://customerRootCA.csr \
    --signing-algorithm SHA256WITHRSA \
	--template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \
    --validity Value=3652,Type=DAYS

# Store the Root CA certificate ARN from the previous output
ROOT_CA_ARN="arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<ca-authority-id>/certificate/<cert-id>"

# 4. Retrieve the Root CA certificate
aws acm-pca get-certificate \
    --certificate-authority-arn $ROOT_CA_AUTHORITY_ARN \
    --certificate-arn $ROOT_CA_ARN \
    --output text > customerRootCA.crt

# 5. Import the Root CA Certificate
aws acm-pca import-certificate-authority-certificate \
    --certificate-authority-arn $ROOT_CA_AUTHORITY_ARN \
    --certificate fileb://customerRootCA.crt

Create and activate a subordinate CA (also known as an intermediate CA):


$ # 6. Create Subordinate CA
aws acm-pca create-certificate-authority \
    --certificate-authority-configuration \
        "KeyAlgorithm=RSA_4096,
        SigningAlgorithm=SHA256WITHRSA,
        Subject={Country=US,Organization=MyOrg,OrganizationalUnit=IT,CommonName=SubordinateCA}" \
    --certificate-authority-type SUBORDINATE

# Store the Subordinate CA Authority ARN from the previous output
SUB_CA_AUTHORITY_ARN="arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<sub-ca-authority-id>"

# 7. Generate Subordinate CA CSR
aws acm-pca get-certificate-authority-csr \
    --certificate-authority-arn $SUB_CA_AUTHORITY_ARN \
    --output text > intermediateCA.csr

# 8. Issue Subordinate CA Certificate using Root CA
aws acm-pca issue-certificate \
    --certificate-authority-arn $ROOT_CA_AUTHORITY_ARN \
    --csr fileb://intermediateCA.csr \
    --signing-algorithm SHA256WITHRSA \
    --template-arn arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1 \
    --validity Value=3651,Type=DAYS

# Store the Subordinate CA certificate ARN from the previous output
SUB_CA_ARN="arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<sub-ca-authority-id>"

# 9. Retrieve Subordinate CA Certificate
aws acm-pca get-certificate \
    --certificate-authority-arn $ROOT_CA_AUTHORITY_ARN \
    --certificate-arn $SUB_CA_ARN \
    --query 'Certificate' \
    --output text > intermediateCA.crt

# 10. Import the Subordinate CA Certificate
aws acm-pca import-certificate-authority-certificate \
    --certificate-authority-arn $SUB_CA_AUTHORITY_ARN \
    --certificate fileb://intermediateCA.crt \
    --certificate-chain fileb://customerRootCA.crt

Combine the certificates into a chain file:


$ cat intermediateCA.crt customerRootCA.crt > chainCA.crt

-----BEGIN CERTIFICATE-----
[Intermediate CA]
-----END CERTIFICATE-----
...
...
-----BEGIN CERTIFICATE-----
[Root CA]
-----END CERTIFICATE-----

Sign the cluster CSR using AWS PCA:


$ aws acm-pca issue-certificate \
    --certificate-authority-arn $SUB_CA_AUTHORITY_ARN \
    --csr fileb://<cluster ID>_ClusterCsr.csr \
    --signing-algorithm SHA256WITHRSA \
    --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
    --validity Value=3650,Type=DAYS

# Store your cluster's cert ARN from the previous output
CLUSTER_CERT_ARN="arn:aws:acm-pca:<region>:<account-id>:certificate-authority/<cluster-cert-arn>"

Download the signed cluster certificate:


$ aws acm-pca get-certificate \
    --certificate-authority-arn $SUB_CA_AUTHORITY_ARN \
    --certificate-arn $CLUSTER_CERT_ARN \
    --output text --query Certificate > <cluster ID>_CustomerHsmCertificate.crt

This command creates a file named <cluster ID>_CustomerHsmCertificate.crt. Use this file as the signed certificate when you initialize the cluster.

Verify the signed certificate against the certificate chain (optional):


$ openssl verify -purpose sslserver -CAfile chainCA.crt <cluster ID>_CustomerHsmCertificate.crt
<cluster ID>_CustomerHsmCertificate.crt: OK

After producing the signed HSM certificate with your intermediate CA, go to Step 4. Initialize the cluster.

Step 4. Initialize the cluster

Use your signed HSM certificate and your signing certificate to initialize your cluster. You can use the AWS CloudHSM console, the AWS CLI, or the AWS CloudHSM API.

Console

To initialize a cluster (console)

Open the AWS CloudHSM console at https://console.aws.amazon.com/cloudhsm/home.
Select the radio button next to the cluster ID with the HSM you want to verify.
Select Actions. From the drop down menu, choose Initialize.
If you did not complete the previous step to create an HSM, choose an Availability Zone (AZ) for the HSM that you are creating. Then select Create.
On the Download certificate signing request page, choose Next. If Next is not available, first choose one of the CSR or certificate links. Then choose Next.
On the Sign certificate signing request (CSR) page, choose Next.
On the Upload the certificates page, do the following:
1. Next to Cluster certificate, choose Upload file. Then locate and select the HSM certificate that you signed previously. If you completed the steps in the previous section, select the file named <cluster ID>_CustomerHsmCertificate.crt.
2. Next to Issuing certificate, choose Upload file. Then select your signing certificate based on the approach you chose:
  - If you chose Option A (single self-signed certificate): Select the file named <customerRootCA>.crt
  - If you chose Option B (certificate chain): Select the file named <chainCA>.crt
3. Choose Upload and initialize.

AWS CLI

To initialize a cluster (AWS CLI)

At a command prompt, run the initialize-cluster command. Provide the following:
- The ID of the cluster that you created previously.
- The HSM certificate that you signed previously. If you completed the steps in the previous section, it's saved in a file named <cluster ID>_CustomerHsmCertificate.crt.
- Your signing certificate based on the approach you chose:
  - If you chose Option A (single self-signed certificate): Use the file named <customerRootCA>.crt
  - If you chose Option B (certificate chain): Use the file named <chainCA>.crt
```
$ aws cloudhsmv2 initialize-cluster --cluster-id <cluster ID> \
                                    --signed-cert file://<cluster ID>_CustomerHsmCertificate.crt \
                                    --trust-anchor file://<customerRootCA.crt OR chainCA.crt>
{
    "State": "INITIALIZE_IN_PROGRESS",
    "StateMessage": "Cluster is initializing. State will change to INITIALIZED upon completion."
}
```

AWS CloudHSM API

To initialize a cluster (AWS CloudHSM API)

Send an InitializeCluster request with the following:
- The ID of the cluster that you created previously.
- The HSM certificate that you signed previously. If you completed the steps in the previous section, it's saved in a file named <cluster ID>_CustomerHsmCertificate.crt.
- Your signing certificate based on the approach you chose:
  - If you chose Option A (single self-signed certificate): Use the file named <customerRootCA>.crt
  - If you chose Option B (certificate chain): Use the file named <chainCA>.crt

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Verify HSM identity (optional)

Install CloudHSM CLI

Initialize the cluster in AWS CloudHSM

Note

Topics

Overview

Step 1. Get the cluster CSR

To get the CSR (console)

To get the CSR (AWS CLI)

To get the CSR (AWS CloudHSM API)

Step 2. Create a private key for your Root CA

Note

Step 3. Sign the CSR

Important

Choose your certificate approach

Create a single self-signed certificate

Sign the cluster CSR with your self-signed Root CA

Create an intermediate certificate authority (ICA) chain

Important

Note

Step 4. Initialize the cluster

To initialize a cluster (console)

To initialize a cluster (AWS CLI)

To initialize a cluster (AWS CloudHSM API)