# Initialize the cluster in AWS CloudHSM
<a name="initialize-cluster"></a>

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](verify-hsm-identity.md). 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
](#initialize-cluster-overview)
+ [

## Step 1. Get the cluster CSR
](#get-csr)
+ [

## Step 2. Create a private key for your Root CA
](#sign-csr-create-key)
+ [

## Step 3. Sign the CSR
](#sign-csr)
+ [

## Step 4. Initialize the cluster
](#initialize)

## Overview
<a name="initialize-cluster-overview"></a>

 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](#get-csr).

## Step 1. Get the cluster CSR
<a name="get-csr"></a>

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](verify-hsm-identity.md), you already have the CSR and you can sign it. Otherwise, get the CSR now by using the [AWS CloudHSM console](https://console.aws.amazon.com/cloudhsm/), the [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/), or the AWS CloudHSM API. 

------
#### [ Console ]

**To get the CSR (console)**

1. Open the AWS CloudHSM console at [https://console.aws.amazon.com/cloudhsm/home](https://console.aws.amazon.com/cloudhsm/home).

1. Select the radio button next to the cluster ID with the HSM you want to verify.

1. Select **Actions**. From the drop down menu, choose **Initialize**.

1. If you did not complete the [previous step](create-hsm.md) to create an HSM, choose an Availability Zone (AZ) for the HSM that you are creating. Then select **Create**.

1. When the CSR is ready, you see a link to download it.  
![\[Download certificate signing request page in the AWS CloudHSM console.\]](http://docs.aws.amazon.com/cloudhsm/latest/userguide/images/download-csr-hsm-cert.png)

1. Choose **Cluster CSR** to download and save the CSR.

------
#### [ AWS CLI ]

**To get the CSR ([AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/))**
+ At a command prompt, run the following **[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/cloudhsmv2/describe-clusters.html)** command, which extracts the CSR and saves it to a file. Replace *<cluster ID>* with the ID of the cluster that you [created previously](create-cluster.md). 

  ```
  $ aws cloudhsmv2 describe-clusters --filters clusterIds=<cluster ID> \
                                     --output text \
                                     --query 'Clusters[].Certificates.ClusterCsr' \
                                     > <cluster ID>_ClusterCsr.csr
  ```

------
#### [ AWS CloudHSM API ]

**To get the CSR (AWS CloudHSM API)**

1. Send a [https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_DescribeClusters.html](https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_DescribeClusters.html) request.

1. Extract and save the CSR from the response.

------

## Step 2. Create a private key for your Root CA
<a name="sign-csr-create-key"></a>

**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
<a name="sign-csr"></a>

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](https://datatracker.ietf.org/doc/html/rfc5280) 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
<a name="certificate-approach-choice"></a>

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](#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](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html).  
Go to: [Create an intermediate certificate authority (ICA) chain](#certificate-chain)

### Create a single self-signed certificate
<a name="self-signed-certificate"></a>

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
<a name="sign-csr-sign-cluster-csr-with-root-ca"></a>

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](#initialize).

### Create an intermediate certificate authority (ICA) chain
<a name="certificate-chain"></a>

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](https://datatracker.ietf.org/doc/html/rfc5280) 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](#initialize).

## Step 4. Initialize the cluster
<a name="initialize"></a>

Use your signed HSM certificate and your signing certificate to initialize your cluster. You can use the [AWS CloudHSM console](https://console.aws.amazon.com/cloudhsm/), the [AWS CLI](https://aws.amazon.com/cli/), or the AWS CloudHSM API. 

------
#### [ Console ]

**To initialize a cluster (console)**

1. Open the AWS CloudHSM console at [https://console.aws.amazon.com/cloudhsm/home](https://console.aws.amazon.com/cloudhsm/home).

1. Select the radio button next to the cluster ID with the HSM you want to verify.

1. Select **Actions**. From the drop down menu, choose **Initialize**.

1. If you did not complete the [previous step](create-hsm.md) to create an HSM, choose an Availability Zone (AZ) for the HSM that you are creating. Then select **Create**.

1. 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**.

1. On the **Sign certificate signing request (CSR)** page, choose **Next**.

1. 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`.

   1. 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`

   1. Choose **Upload and initialize**.

------
#### [ AWS CLI ]

**To initialize a cluster ([AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/))**
+ At a command prompt, run the **[initialize-cluster](https://docs.aws.amazon.com/cli/latest/reference/cloudhsmv2/initialize-cluster.html)** 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 [https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_InitializeCluster.html](https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_InitializeCluster.html) 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`

------