When a TLS certificate is compromised before its expiry date, it needs to be revoked. CRL and OCSP are the two main mechanisms browsers and clients use to check whether a certificate has been revoked. Both have significant practical limitations.
| Feature | CRL | OCSP |
|---|---|---|
| RFC | RFC 5280 | RFC 6960 |
| Mechanism | Download a signed list of revoked serial numbers | Query a responder for one certificate's status |
| Response size | Can be large; grows as revocations accumulate | Small; per-certificate response |
| Caching | Cached; stale until next update interval | Cached; response has a validity window |
| Privacy | No per-certificate contact with CA | CA learns which certificates clients visit |
| Soft-fail behavior | Fails open if list unavailable | Fails open if responder unreachable |
| Stapling | Not applicable | Server can staple OCSP response in handshake |
A CRL is a signed document issued by a Certificate Authority that lists the serial numbers of certificates it has revoked before their expiry date. Clients download the CRL from a URL embedded in the certificate, cache it locally, and consult it when evaluating a certificate. The CA updates and re-signs the CRL periodically.
The practical problem with CRLs is size and freshness. A CA that issues many certificates accumulates a growing list of revocations. Downloading a large CRL on every TLS connection is slow, so clients cache CRLs for the full update interval — which means a newly revoked certificate may continue to be accepted by clients that have a cached CRL that does not yet include it.
OCSP takes a different approach: instead of downloading a full list, the client sends the serial number of the specific certificate it is evaluating to an OCSP responder operated by the CA, and the responder returns a signed status response — good, revoked, or unknown. The response has a validity window and can be cached for that duration.
OCSP has a well-known weakness called soft-fail. If the OCSP responder is unreachable (due to network issues, rate-limiting, or an attacker blocking access), most clients proceed with the TLS connection anyway rather than blocking the user. The alternative — hard-fail, where an unreachable responder causes the connection to be refused — was considered too disruptive because it would make OCSP responders a single point of failure for the web.
OCSP stapling addresses both the privacy and soft-fail problems. Instead of the client contacting the CA's responder, the server fetches the OCSP response itself and attaches (staples) it to the TLS handshake as a TLS extension. The client receives the revocation status directly from the server. Because the OCSP response is CA-signed and carries its own validity period, the client can verify it independently. Stapling means clients never contact the CA directly (preserving privacy), and the server controls freshness by periodically refreshing the stapled response.
Neither CRL nor OCSP provides reliable, real-time revocation checking at the scale of the modern web. The soft-fail behavior common to both means revocation is not enforced when infrastructure is unavailable. The browser ecosystem has moved toward shorter certificate lifetimes and aggregated, browser-vendor-managed revocation datasets as complementary approaches to reducing the impact of a compromised certificate. OCSP stapling remains a recommended practice for servers because it shifts the operational burden from clients to servers and improves connection latency by avoiding a round-trip to the CA during the handshake.