How TLS Certificate Revocation Checks Differ: OCSP Stapling and CRLite
Certificate revocation checks balance timely status information with connection reliability and privacy. Compare TLS OCSP stapling with CRLite’s browser-side compressed revocation data, separating protocol rules from implementation-specific evidence.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Why is revocation a separate problem?
A TLS certificate is a certificate authority’s signed statement connecting a public key with a domain name. A certificate may need to be distrusted before its expiry—for example, after a private-key compromise or a misissuance. A browser that checks only the expiry date can miss this intermediate change, so certificate-status mechanisms are needed. Yet synchronously contacting an external status service for every connection can add delay, create an availability dependency, and reveal visited hosts to the party receiving those queries.
A certificate revocation list (CRL) is the traditional way to distribute revoked certificates to clients. As the list grows, transfer and storage costs rise, and operators must trade update frequency against distribution delay. OCSP answers the status of an individual certificate, reducing the amount of data a client needs, but a browser that contacts the responder directly still depends on its availability and adds a network round trip. Both approaches therefore involve freshness, performance, and privacy choices.
What does OCSP stapling change?
The TLS status_request extension in RFC 6066 lets a client request certificate-status information. A server can attach an OCSP response to the TLS handshake alongside its certificate. The browser no longer needs to contact the OCSP responder itself for each connection, which can reduce round-trip delay and exposure of browsing destinations. The client still has to validate the response; RFC 6066 says a client that receives an unsatisfactory response must abort the handshake.
Stapling depends on the server having a valid, current response ready. An expired response, a failed refresh, or a mismatch between the response and certificate can leave the client without the expected status evidence. RFC 6066 is a TLS 1.2-era extension document, not a complete guide to every current TLS certificate-validation policy. Actual behavior varies with browser policy, TLS version, certificate extensions, and deployment configuration.
Expert perspective: reliability depends on server operations
A Cloudflare engineering article describes the company’s design at the time: collect OCSP responses centrally rather than on each request, refresh them as expiry approaches, and distribute valid responses to its servers. The article explains how a response’s validity period provides room to retry and recover from a failed fetch. This is a provider-specific historical account, not a guarantee that every certificate authority or hosting provider offers the same reliability today.
With ordinary direct OCSP retrieval, a soft-fail policy can preserve availability when the responder cannot be reached, but it may miss a revoked certificate if an attacker suppresses the status response. A policy that requires a staple can enforce a stronger signal by failing the connection when the response is absent; it can also turn a legitimate server refresh outage into a user-visible failure. A hard-fail design is only operationally sound when the assumption that a valid staple will always be available is actually maintained.
CRLite moves the data to the browser
Mozilla’s CRLite/Clubcard research explores encoding large revocation sets into compressed membership data that a browser can check locally. Because the browser need not send a per-site OCSP query each time, this approach can reduce query latency and the disclosure of individual visited hosts. The paper evaluates compression size, update traffic, filter-refresh design, and an implementation in Firefox Nightly.
Using late-2024 WebPKI data, the paper reports a 6.7 MB full snapshot and average six-hour deltas of 26.8 kB. The authors say clubcard-based CRLite became the default revocation-checking method in Firefox Nightly 134 and handled about 93% of checks in their study. These are results for that paper’s dataset, period, and Nightly environment; they do not establish the default in every current Firefox or browser, or immediate global updates. Compressed data still needs scheduled distribution and validation, and handling stale snapshots or missed updates remains an operational concern.
Questions for comparing the approaches
OCSP stapling delivers a short-lived status response from the server, while CRLite asks the client to query a compressed revocation set. For the former, response refresh and distribution reliability are central; for the latter, update cadence, storage, and validation of large data are central. Neither replaces certificate issuance controls, private-key protection, trust stores, or the browser’s overall validation policy.
For a system design, identify supported browsers and TLS versions first, then document what happens when a response is missing or stale. Measure privacy, latency, behavior during network outages, data freshness, and recovery paths together. Verify current product behavior against its documentation and actual configuration.