Certificate revocation CRL vs OCSP vs CRLSets

How revocation works

A TLS certificate is revoked when it should stop being trusted before its expiry date, for example because the private key leaked or the certificate was issued by mistake. Without a fresh way to say "this certificate is no longer valid", a leaked key stays trustworthy until expiry, which is dangerous.

Revocation is separate from expiry. An expired certificate is rejected by the browser's clock check. A revoked certificate must be checked against a revocation source, and how reliably that check happens differs sharply between the mechanisms.

CRL vs OCSP

• Certificate Revocation List (CRL): the CA publishes a periodically-updated list of revoked serial numbers. Clients fetch the whole list, which grows over time and can be huge. This was the original mechanism and is still published by CAs as a baseline.
• OCSP (Online Certificate Status Protocol): a client queries an OCSP responder with the certificate serial number and receives a one-off live status (good, revoked, or unknown). It avoids downloading a whole list.
• OCSP stapling: the server fetches a time-stamped OCSP response from the CA and attaches it to the TLS handshake, so the client does not make a separate request. This moves the fetch off the client and onto the server.

The trade-off in the list-vs-live pair is cost and freshness. CRLs are cheap to serve but frequently out of date and heavy. OCSP is fresh but adds a network round trip per connection unless it is stapled, and an unreachable responder creates a choice between failing closed or silent pass.

Modern browser practice

The practical reality is that browsers no longer treat OCSP as a hard revocation check on every connection:

• Chrome stopped counting OCSP as a blocking check for public certificates; it relies on CRLSets, small curated lists of high-value revoked certificates pushed to clients, rather than fetching per-connection status. It also stopped counting OCSP timestamps toward certificate validation in newer releases.
• Firefox uses CRLite, a compact database of revoked certificates downloaded and queryable locally.
• Safari continues to check OCSP by default, querying the CA responder when it can.

The shared theme is that per-connection OCSP lookups proved too slow, unreliable, and privacy-sensitive to sustain, so the engines that can cache locally moved toward pre-bundled revocation data (CRLSets and CRLite) while Safari kept live OCSP.

As a site operator you cannot control which mechanism a visitor's browser uses. What you can do is keep the certificate valid, publish an accurate CRL if your CA provides one, and serve OCSP stapling from the origin so the small step that does still run is cheap. Set up the headers and stapling described in OCSP stapling, review certificate hierarchy so the chain is correct, and treat certificate errors reports as the signal that a chain or revocation link is broken.