Certificate Revocation: OCSP, CRL and Stapling
Sometimes a certificate must be invalidated before it expires — a stolen private key, a mis-issuance, a decommissioned service. Revocation is how a CA says "do not trust this certificate any more," and there are two mechanisms plus an optimization.
CRL vs OCSP
| Method | How it works | Drawback |
|---|---|---|
| CRL | CA publishes a signed list of revoked serial numbers; clients download it | Lists get large; cached for hours |
| OCSP | Client asks the CA's responder about one certificate in real time | Latency + privacy (CA sees what you visit) |
Both are referenced in the certificate: the CRL Distribution Point and the AIA "OCSP URI."
OCSP stapling and Must-Staple
OCSP stapling fixes OCSP's latency and privacy problem: the server fetches a signed, time-stamped OCSP response and "staples" it into the TLS handshake, so the client doesn't contact the CA at all. Must-Staple is a certificate flag that requires a valid stapled response, closing the "soft-fail" gap where browsers accept a certificate when the OCSP responder is unreachable.
The reality
Browser revocation checking is famously inconsistent — many soft-fail, so a revoked certificate may still be accepted if checks can't complete. This is one reason certificate lifetimes keep shrinking: a short-lived certificate limits the window of misuse better than revocation does. See checking certificate expiry.
Verify a server's OCSP status, stapling and chain with Slogical's detailed SSL checker; the basic SSL/TLS checker here covers expiry and chain. Background: the certificate chain.
Note: Stapling shifts the OCSP fetch to your server, so monitor it — a server that staples a stale or failed response can break clients that enforce Must-Staple.