Skip to main content
Smallstep step-ca is an open-source online certificate authority for internal Public Key Infrastructure (PKI). It issues X.509 certificates for mutual TLS between services, SSH host and user certificates, and short-lived workload identities, and it automates renewal through ACME and its own provisioner model. This integration connects step-ca to CryptoHub through the Futurex PKCS #11 (FXPKCS11) module. step-ca loads FXPKCS11 as a PKCS #11 key management system, and the CA signing key stays on the appliance: step-ca builds each certificate locally, sends the signing operation to CryptoHub over the Host API, and embeds the returned signature. The private key is never written to the CA host.

​
Key features

This integration has the following features:
  • Private certificate authority: Run an internal CA that issues X.509 certificates for your own services without depending on a public CA.
  • PKCS #11 key management: Reference the CA signing key through a standard PKCS #11 URI, so step-ca performs every signature on the appliance.
  • Automated certificate lifecycle: Issue and renew certificates through step-ca provisioners and the step CLI.
  • Mutual TLS: Issue both server and client certificates from one CA to authenticate service-to-service traffic in both directions.
  • Workload identity: Bind short-lived certificates to workloads rather than to long-lived static secrets.
  • SSH certificate authority: Issue SSH host and user certificates from the same CA deployment.
  • API-driven automation: Drive issuance from the step CLI or the step-ca HTTPS API, so certificate operations fit into existing pipelines.

​
Benefits of CryptoHub integration through PKCS #11

Integrating with CryptoHub provides the following benefits:
  • Enhanced security: The intermediate CA signing key is generated on the CryptoHub as a non-extractable token object, so a compromise of the CA host does not yield the key that signs your certificates.
  • Hardware-backed certificate authority: Every certificate the CA issues is signed inside a Futurex HSM rather than by a key file on disk.
  • Centralized key management: CryptoHub provides one repository for CA signing keys, which simplifies access review, rotation, and audit.
  • Policy-based controls: CryptoHub identity and permission controls govern which application identities can use the CA signing key.
  • Efficient cryptographic operations: Futurex HSMs handle signing efficiently, so hardware protection adds minimal latency to issuance.
  • Compliance readiness: Storing CA keys in a CryptoHub helps you meet requirements that mandate hardware protection for certificate authority private keys.
  • Operational resilience: CryptoHub high-availability and failover features keep the signing path available during a system failure.
  • Standards-based integration: step-ca reaches CryptoHub through its built-in PKCS #11 support and the FXPKCS11 module, with no custom code and no vendor-specific plugin.

​
Architecture

This integration runs across two runtimes on one Linux host. The host toolchain provides the step CLI and the step-kms-plugin. You use it to create the CA configuration, generate and inspect the CryptoHub-resident key, issue the HSM-backed intermediate certificate, and drive certificate requests against the running CA. The CA process runs in the smallstep/step-ca:hsm container image. Official step-ca packages and binaries are compiled without PKCS #11 support, so the long-running CA must be the :hsm image. The container mounts the host ~/.step directory and the FXPKCS11 directory, then reads the same ca.json the host toolchain produced. The FXPKCS11 module (libfxpkcs11.so) and its configuration file (fxpkcs11.cfg) sit in /usr/local/lib/fxpkcs11 on the host and are mounted read-only into the container. The module opens a mutual TLS session to the CryptoHub Host API on TCP port 2001 and carries every signing request.
Only the intermediate CA is HSM-backed in this integration. step ca init creates a software root CA whose private key remains in ~/.step/secrets on the host, and that root signs the HSM-backed intermediate exactly once. The intermediate is the key that signs certificates continuously, so it is the key that benefits from hardware protection. Keep the root key offline after the intermediate is signed.

​
Out of scope

This guide documents a single-node CA that issues its first certificate from a CryptoHub-resident key. The following topics are not covered:
  • High-availability or multi-node step-ca deployments.
  • CA key rotation and intermediate CA renewal.
  • ACME provisioners and automated certificate renewal.
  • Running step-ca as a systemd service or under an orchestrator.
  • SSH certificate authority configuration.
For those topics, refer to the Smallstep step-ca documentation after you complete this integration.