The CA key model
This guide uses two CA tiers:- The root key remains encrypted on the step-ca host. Use it only to sign the intermediate certificate, then protect it as an offline root.
- The intermediate private key remains nonexportable in CryptoHub. The running CA uses this key for routine certificate issuance.
How it works
Thesmallstep/step-ca:0.30.2-hsm container loads the endpoint-delivered libcryptohub-pkcs11.so module through Smallstep’s native PKCS #11 KMS. The module authenticates from the protected UserPass credential in cryptohub.json and connects to CryptoHub over TLS on TCP 443.
When step-ca issues a certificate:
- The requester sends a certificate request to step-ca.
- step-ca builds the certificate data and asks its PKCS #11 signer to sign it.
- The CryptoHub Client Library sends the signing operation to the Smallstep service in CryptoHub.
- CryptoHub uses the intermediate key in the HSM and returns only the signature.
- step-ca assembles and returns the issued certificate.
Why this route uses the HSM image
Smallstep’s standardstep-ca release binary is compiled without CGO and rejects a PKCS #11 KMS. The 0.30.2-hsm image includes the CGO-enabled CA and the step-kms-plugin needed to load a native PKCS #11 module.
An OpenSSL provider is not part of this integration. step-ca loads the CryptoHub module directly through its own KMS configuration.
Validated scope
This guide covers:- CryptoHub 7.3.0.x build 7.3.0.0b or later in that branch.
- Smallstep step-ca
0.30.2-hsmon a Linux x86-64 Docker host. - step CLI 0.30.6 and step-kms-plugin 0.17.0.
- One software root and one CryptoHub-backed RSA-3072 intermediate.
- UserPass endpoint authentication over the CryptoHub REST API.
- Leaf issuance, independent chain verification, and issuance after a container restart.

