Revocation — OCSP & CRL
Publish revocation status so relying parties can trust — or reject — a certificate in real time.
Data flow
Revocation through CRL and OCSP
A revoked certificate is published through the CA's CRL and OCSP responder, so relying parties can reject it in batch or in real time.
Revoking a certificate
Certificates and CAs are revoked with a standard RFC 5280 reason (for example keyCompromise, cessationOfOperation, certificateHold). A revocation immediately affects both publication channels: the CA's CRL and its OCSP responder. A held certificate (certificateHold) can later be reinstated via reactivation (removeFromCRL).
CRL — Certificate Revocation Lists
Each CA generates a signed CRL in PEM form, published at the CRL distribution URL carried in issued certificates. CRLs can be generated on demand or forced, and inspected for their metadata (CRL number, this/next update).
Set each CA's CRL distribution URL when you create it, so every issued certificate carries a working download point (see CA Management).
OCSP — Online Certificate Status Protocol
For real-time status without downloading a full list, each CA can run an OCSP responder. Responders have their own lifecycle (deploy, start, pause, stop) plus health and metrics, and use a dedicated OCSP signer certificate.
The CA's AIA OCSP URL is embedded in issued certificates, so relying parties know where to send status queries. Configure it on the CA alongside the CRL distribution URL.
Choosing CRL, OCSP, or both
| Mechanism | Best for |
|---|---|
| CRL | Offline / batch validation; clients that cache a periodic list |
| OCSP | Real-time, per-certificate status checks |
| Both | Publish both and let each relying party use what it supports — the recommended default |