Typically, when using EJBCA and creating CryptoTokens, a CryptoToken will generally look at a slot in an HSM for its key material.

When using CloudHSM, the CloudHSM client provided by AWS always looks at a single cluster of HSMs. This cluster is always referenced as slot 1 to the host accessing it.

AWS' CloudHSM client does not allow a host to access more than one CloudHSM cluster at a time. EJBCA can have a multi-tier CAs, but because of the CloudHSM clients ability to only talk to a single HSM cluster, it is advised to have a dedicated offline root CA that can sign your issuing CAs. In this scenario, a Root CA would sign an Issuing CA as an external CA. 

For more information on signing an external CA, refer to the EJBCA documentation on Signing an External CA.

There are two ways to accomplish this. On a single host, or a second off-line Root CA host.

Scenario 1 - Two instances:

  1. Start two EJBCA Enterprise Cloud instances
  2. Initialize the CloudHSM client on each instance to talk to each cluster, see 5 - Configure the cloudhsm-client.
  3. Create the self signed Root CA on instance 1.
  4. Create the issuing CA on instance 2 and set it to be signed by an external CA, see Signing an External CA.
  5. Download the CSR from the issuing CA on instance 2.
  6. Sign the CSR on instance 1 with the Root CA.
  7. Bring the signed certificate back to instance 2 and fulfill the waiting CAs CSR.

Scenario  2 - Single instance

  1. Start a single EJBCA Enterprise Cloud instance
  2. Initialize the CloudHSM client on the instance to talk to the first CloudHSM cluster, see 5 - Configure the cloudhsm-client.
  3. Create the self signed Root CA.
  4. Reconfigure the CloudHSM client to talk to the second CloudHSM cluster.
  5. Restart EJBCA/WildFly
  6. Create the issuing CA and set it to be signed by an external CA, see Signing an External CA.
  7. Download the CSR from the issuing CA
  8. Reconfigure the CloudHSM client to talk to the first CloudHSM cluster.
  9. Restart EJBCA/WildFly
  10. Sign the CSR with the Root CA.
  11. Reconfigure the CloudHSM client to talk to the second CloudHSM cluster.
  12. Restart EJBCA/WildFly
  13. Bring the signed certificate back to the issuing CA and fulfill the waiting CAs CSR.

A single instance can have more than one issuing CA on it.  Just create the three keys for each CA in a single Crypto Token.  For example in a single CryptoToken, you might have the following keys:

  • IssuingCA1_signKey0001
  • IssuingCA1_defaultKey0001
  • IssuingCA1_testKey0001
  • IssuingCA2_signKey0001
  • IssuingCA2_defaultKey0001
  • IssuingCA2_testKey0001

Although you can have all of the keys for a Root CA and an Issuing CA in the same CryptoToken, this is not advisable since the Root CA would always need to be online so the Issuing CA can run.