CA Management
Create and operate certificate authorities — root, intermediate and external — with a full, auditable lifecycle.
Tree
Certificate authority hierarchy
An offline root signs issuing intermediates, which issue the leaf certificate types.
CA types
A certificate authority is created inside the platform. When you select a vault, its signing key is generated and held in that vault — software vault, HSM, cloud KMS or MPC cluster — and is never exported; every certificate, CRL and OCSP response is signed there. Without a vault, a classical CA uses a software key stored by the platform. See CA Key Protection for the supported back-ends per algorithm and for migrating existing CAs.
| Type | How it is created | Typical role |
|---|---|---|
| Root CA | Self-signed | Offline trust anchor at the top of the hierarchy |
| Intermediate / issuing CA | Signed by a parent root or intermediate | The CA that issues day-to-day certificates |
| External CA | Imported from an existing PKI | Track and manage a CA operated elsewhere |
When creating an intermediate under a post-quantum or hybrid parent, the platform enforces parent-algorithm compatibility so the chain remains verifiable. PQC and hybrid CAs are vault-signed; classical CAs are vault-signed when created with a vault.
CA subject and constraints
Each CA is configured with its subject (CN, O, OU, C, ST, L), a configurable path-length constraint, the signing hash algorithm, the key type / size, and the distribution URLs published into issued certificates:
| Setting | Purpose |
|---|---|
| Path-length constraint | How many sub-CAs may sit below this CA |
| AIA OCSP URL | Authority Information Access — where relying parties fetch OCSP |
| CRL distribution URL | Where relying parties fetch the CRL |
| Signing key | A key generated and held in the selected vault (HSM, cloud KMS, MPC), or a software key stored by the platform |
Building a hierarchy
Create the root CA
Create a self-signed root with a long validity and a restrictive path-length constraint. Keep it for signing intermediates only.
Create an issuing intermediate
Create an intermediate signed by the root. Day-to-day certificates are issued from the intermediate, so the root can stay offline.
Publish distribution points
Set the AIA OCSP and CRL distribution URLs so issued certificates carry working revocation endpoints.
Issue
Issue certificates under the intermediate — directly, via the request workflow, or through the enrollment protocols.
CA lifecycle
Every CA supports a complete, audited lifecycle. Each action is gated by fine-grained role-based permissions, and revocation, archive and CA changes can additionally require M-of-N quorum approval.
| Action | Effect | RFC 5280 |
|---|---|---|
| Suspend | Temporarily hold the CA | certificateHold |
| Reactivate | Lift a suspension | removeFromCRL (reason 8) |
| Revoke (simple) | Permanently revoke this CA | — |
| Revoke (cascade) | Revoke this CA and all sub-CAs and issued certificates | — |
| Archive / Unarchive | Hide a non-issuing CA from lists and pickers | — |
Before any cascading action, request a lifecycle-impact preview — a read-only report of exactly which sub-CAs and certificates a cascade would affect. Archive is only allowed once a CA has stopped issuing.
Chain, CRL and OCSP
Each CA can publish its full certificate chain, generate and serve a CRL, and expose an OCSP responder for real-time status. See Revocation (OCSP & CRL) for details.
API reference
Every CA action — create a root or intermediate, retrieve the chain, preview lifecycle impact, suspend, reactivate, revoke, cascade revoke, archive and generate a CRL — is also available programmatically through the platform API.