CA Key Protection
Generate CA signing keys in an HSM, a cloud KMS or an MPC cluster, and sign every certificate, CRL and OCSP response there.
Overview
A certificate authority created with a vault keeps its private key in that vault. The key is generated there, only the public key is read back, and nothing is exported or stored with the CA. This applies to classical RSA and ECDSA CAs as well as to post-quantum and hybrid CAs.
A CA created without a vault still works: its key is generated in software and stored by the platform with the CA. The CA detail page shows which case applies (see Key custody), and existing CAs can be moved into a vault (see Migrating an existing CA).
How vault-resident CA keys work
Key generation in the vault
When you create a root or intermediate CA and select a vault, the key pair is generated in that vault. Cockpit reads back the public key only.
Probe signature
Before the CA certificate is built, Cockpit asks the vault for one test signature and verifies it. If the key cannot sign correctly, CA creation fails and the vault key is deleted.
Every signature is made in the vault
The CA certificate, issued certificates, CRLs, OCSP responses and enrollment-protocol responses (ACME, EST, CMP, Windows autoenrollment, cert-manager) are all signed by the vault.
Every signature is checked before use
Each signature returned by the vault is verified against the CA public key before it is placed in a certificate, CRL or OCSP response. A back-end that signs with the wrong key, padding or hash fails closed instead of producing an invalid certificate.
Each signature costs one round trip to the vault. For high-volume issuance, place the vault close to the Cockpit deployment.
Key custody
The CA detail page shows a key custody badge (also returned by the CA API as key_custody):
| Custody | Meaning |
|---|---|
vault | The key exists only in the bound vault, HSM, cloud KMS or MPC cluster |
vault_pqc | Post-quantum or hybrid CA, signed in the vault |
legacy_exportable | A software copy of the key is still stored with the CA and a vault key is bound (a CA created before vault-resident classical keys were available, or a CA being migrated) |
local_database | The key is stored by the platform with the CA; no vault is bound |
none | No usable signing key |
Supported back-ends
The CA wizard only offers the algorithms that the selected vault can hold and sign with.
| Vault back-end | Classical CA keys |
|---|---|
| Software Vault | RSA-2048, RSA-4096, EC P-256, EC P-384 |
| Securosys Primus HSM | RSA, EC |
| Azure Key Vault / Managed HSM | RSA, EC |
| Network HSMs through the DuoKey PKCS#11 REST proxy (see Vaults) | RSA, EC |
| On-premises HSM agent, DuoKey Software HSM | RSA, EC (requires the current agent version) |
| AWS KMS | EC only |
| Google Cloud KMS | EC only |
| HashiCorp Vault / OpenBao Transit | EC only |
| Sepior (Blockdaemon) MPC | EC P-256 only |
| Alibaba Cloud KMS | EC P-256 only |
Post-quantum and hybrid CAs are unchanged: they need a vault that generates and signs post-quantum keys (Software Vault or Securosys), see Post-Quantum PKI.
Signing behaviour differs between HSM models, firmware versions and cloud KMS configurations. Before moving a production CA, create a test CA on the same vault and issue, revoke and publish a CRL with it. Contact DuoKey to confirm the qualification status of your specific HSM or KMS.
MPC-protected CA keys
A CA can be bound to an MPC vault. Its certificates, CRLs and OCSP responses are then signed by the MPC cluster: the private key is never assembled in one place, neither in Cockpit nor in any single MPC node.
| MPC back-end | CA key algorithms | Notes |
|---|---|---|
| Sepior (Blockdaemon) MPC, through the DuoKey KMS API | ECDSA P-256 only | RSA and P-384 CA keys are refused at CA creation, because the MPC signing service signs ECDSA P-256 / SHA-256 only |
| DuoKey Software HSM / Managed MPC (PKCS#11 through the HSM agent) | RSA, EC | Requires the current HSM agent version, which returns the public key of the MPC key |
MPC-protected CA keys are available as a preview. Validate CA creation, issuance and CRL publication on your MPC vault before using it for a production CA. If the MPC service does not return a usable public key, CA creation fails with an explicit error; it never produces a CA with a wrong key.
Requiring vault-resident CA keys
On-premises deployments can refuse new classical CAs without a vault with the deployment setting DKE_PKI_REQUIRE_VAULT_CA_KEYS=true. No new software CA keys can then be created. The setting is off by default. On DuoKey-hosted tenants, ask DuoKey support to apply it.
Migrating an existing CA
CAs whose custody is local_database or legacy_exportable can be moved to a vault without changing the CA certificate. All three operations need the Operations.Pki.CAs.Update permission.
Import the existing key into the vault (optional)
POST /api/pki/cas/{id}/key/import-to-vault with vault_id imports the stored key through the vault's key-import (BYOK) interface and binds it. Today this is available for Azure Key Vault / Managed HSM only; other vaults answer 400. For an HSM, import the key with the HSM vendor's own tooling instead and continue with step 2.
Bind the CA to the vault key
POST /api/pki/cas/{id}/key/bind-vault-key with vault_id and key_external_id. The binding is refused unless the vault key's public key is identical to the CA certificate's and a probe signature verifies. The stored copy is kept at this stage (custody legacy_exportable).
Purge the stored key
POST /api/pki/cas/{id}/key/purge-stored-key erases the software copy. It is refused unless the CA is bound to a vault key that passes the same checks. From then on the CA signs only in the vault (custody vault).
If the existing key was ever held in software and you want a key that has only ever existed in hardware, create a new CA with a vault-resident key and issue from it. The old CA keeps serving its CRL and OCSP for the certificates it issued until they expire.
Limits
- SCEP cannot be served from a vault-resident CA. SCEP decrypts the enrollment envelope with the CA key (RSA PKCS#1 v1.5 decryption), which vault back-ends do not offer for CA keys. A SCEP profile therefore needs an RSA CA whose key is held in software by the platform; binding a SCEP profile to a vault-resident CA is refused.
- secp256k1 CAs cannot be vault-resident.
- Software Vault: a vault-resident CA key generated in the Software Vault is stored as a sealed, non-exportable key named
CA signing key - <CN>. Deleting that key leaves the CA unable to sign. - CA creation adds one probe signature, and every signature one round trip to the vault.
API
| Method and path | Purpose | Permission |
|---|---|---|
GET /api/pki/cas/{id} | CA details, including key_custody | Operations.Pki.CAs.Read |
GET /api/vaults/{id}/key-types | Algorithms a vault can hold as CA key (pki_signing_algorithms[].ca_key_in_vault) | Operations.Vaults.Read |
POST /api/pki/cas/{id}/key/import-to-vault | Import the stored key into the vault and bind it | Operations.Pki.CAs.Update |
POST /api/pki/cas/{id}/key/bind-vault-key | Bind the CA to an existing vault key | Operations.Pki.CAs.Update |
POST /api/pki/cas/{id}/key/purge-stored-key | Erase the stored software key | Operations.Pki.CAs.Update |
A CA or vault of another tenant answers 404.