CA Management
Create and operate certificate authorities — root, intermediate and external — with a full, auditable lifecycle.
CA types
A certificate authority is created inside the platform; its signing key is generated locally for classical CAs, or held in the vault for post-quantum and HSM-protected 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 can sign locally.
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 vault-backed signing key, or a locally generated key |
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.
| 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.