Why Revocation Is Needed
Every certificate carries an expiry date, and once past it, clients reject it automatically. But plenty of things can make a certificate untrustworthy before that date:
- The private key is compromised — stolen or leaked — so an attacker could impersonate the site.
- The certificate was issued in error, or to someone who should not have received it.
- The information changed — the domain changed hands, or the organization no longer exists.
In each case the certificate's signature is still mathematically valid, so nothing about the certificate itself signals the problem. The certificate authority must actively announce "this one is no longer to be trusted," and clients must find out. Those two needs — publishing the revocation and checking it — are what CRLs and OCSP address, in different ways.
CRL: The Revocation List
The original approach is the certificate revocation list. The CA maintains a signed list of the serial numbers of every certificate it has revoked. Clients download this list and, when validating a certificate, check whether its serial number appears on it. If it does, the certificate is rejected.
The model is simple and the list is signed so it cannot be forged, but it scales poorly. A busy CA's list can grow very large, and a client either downloads a big file or works from a cached copy that may be hours or days out of date. There is an inherent lag between a certificate being revoked and the list that says so reaching everyone — and during that lag, the revoked certificate still looks fine to anyone with a stale list.
OCSP: Asking About One Certificate
The Online Certificate Status Protocol flips the model. Instead of downloading every revocation and searching it, the client asks the CA about one specific certificate: "is serial number X still good?" The CA's OCSP responder replies with a small, signed answer — good, revoked, or unknown. It is far more targeted than hauling down an entire list, and the answer is fresh.
But OCSP introduces its own problems. It adds a real-time network request to the start of many connections, which costs time. If the OCSP responder is slow or unreachable, the connection stalls waiting for it. And there is a privacy cost that is easy to miss: because the client asks the CA about each certificate it encounters, the CA effectively learns which sites that client is visiting. A revocation check should not double as a browsing-history feed to a third party.
| CRL | OCSP | |
|---|---|---|
| How it works | Download a list of all revoked serials | Ask about one certificate, get a live answer |
| Freshness | As fresh as your cached list | Real-time |
| Cost | Large download / stale cache | A lookup per connection |
| Privacy | No per-site leak | CA learns which sites you visit |
OCSP Stapling: The Best of Both
The fix for OCSP's drawbacks is clever: move the lookup from the visitor to the server. With OCSP stapling, the web server periodically asks the CA for a signed status of its own certificate, then attaches — "staples" — that fresh, signed proof to the TLS handshake it sends to every visitor. The client gets up-to-date revocation status without making any request of its own.
This solves all three OCSP problems at once. There is no per-connection lookup from the client, so no added latency; the responder being slow affects only the server's occasional refresh, not visitors; and because the client never contacts the CA, nothing about its browsing leaks. Stapling is now the preferred way to deliver OCSP status, and it is widely supported.
Why Revocation Is Still Hard — and the Modern Answer
Even with stapling, revocation has a stubborn weakness: the soft-fail problem. If a client cannot get a revocation answer — the list is unreachable, the responder times out — what should it do? Blocking the user every time a check fails would make the web fragile, so most clients soft-fail: they assume the certificate is fine and continue. But that means an attacker who can simply block the revocation check can keep using a revoked certificate, because the client will shrug and proceed. Revocation that an adversary can switch off is not a strong guarantee.
The modern response sidesteps the problem rather than solving it head-on: short-lived certificates. If a certificate is valid for only a few days instead of a year, the window in which a compromised one can be abused shrinks dramatically — it expires on its own almost immediately. Rather than revoke and hope every client notices in time, you simply let the short certificate lapse and replace it through automation. This is why certificate lifetimes have been falling steadily: the most reliable revocation is a certificate that was never going to last long anyway. It fits naturally into the broader PKI trend toward automated, frequently rotated certificates.
Frequently Asked Questions
What is certificate revocation?
Declaring a certificate invalid before its expiry date so clients stop trusting it. It is needed when a private key is compromised, a certificate was issued in error, or its details are no longer true. Since a certificate is valid until it expires, revocation is the only way to cancel one early.
What is the difference between a CRL and OCSP?
A CRL is a signed list of all revoked certificates that a client downloads and checks against. OCSP lets a client ask the authority about one specific certificate and get a live answer. CRLs can be large and stale; OCSP is targeted but adds a real-time lookup to connections.
What is OCSP stapling?
The web server, not the visitor, fetches the OCSP status of its own certificate periodically and staples that signed proof to the TLS handshake. The client gets OCSP freshness without its own lookup — faster, and without leaking the visitor's browsing to the CA.
Why is certificate revocation considered unreliable?
Because clients often cannot get a timely answer. CRLs may be large or stale, OCSP servers can be slow or unreachable, and most browsers soft-fail — treating a certificate as valid when the check cannot complete. An attacker who blocks the revocation check can keep using a revoked certificate.
How do short-lived certificates help with revocation?
A certificate valid for days rather than a year limits the damage window if compromised, since it expires almost immediately. This reduces reliance on unreliable revocation — you let the short certificate lapse and replace it through automation instead of revoking and hoping clients notice.