OCSP stapling and certificate revocation

When you connect to an HTTPS site, the browser should check that the certificate has not been revoked before its expiry. The classic way to do that is OCSP, a protocol in which the client asks the certificate authority whether a certificate is still valid. OCSP stapling moves that proof server-side: the web server fetches the signed OCSP response from the CA and sends it to the client inside the TLS handshake, so the visitor never talks to the CA itself. This was faster and more private, and it is now part of a larger industry shift away from OCSP.

What stapling does

Without stapling, each browser independently contacts the CA's OCSP responder to ask about a certificate, leaking to the CA which site the visitor browsed and adding a network request to every connection. With stapling, the server presents a short-lived, CA-signed statement ("this certificate is not revoked") during the handshake, and the client accepts it without a separate query. The benefit is a privacy improvement and a latency win, because the check rides along in a connection that is already happening.

Why the ecosystem stepped back

OCSP has two structural problems that pushed the industry in a different direction:

1. The responder is a single point of failure and latency. A slow or down OCSP responder delays or breaks the handshake, and in practice most browsers soft-fail (accept without a definitive answer) rather than risk blocking the connection. That makes OCSP unreliable as a security gate.
2. The query leaks browsing behaviour. Every OCSP query tells the CA which site a user is visiting, which is the privacy cost stapling was designed to remove but that stapling itself never fully solved.

The response has been a move to push-based revocation: browsers ship a compact list of revoked certificates in their updates instead of asking per connection. That is the direction Chrome's CRLSets and Mozilla's CRLite take, and it removes the per-connection query and the CA leak entirely.

The current picture

The shift is visible in concrete changes:

• Major public CAs have retired their OCSP responders. A certificate issued today by such a CA often has no OCSP responder to call; the expected revocation path is a certificate revocation list (CRL) or a short-lived certificate.
• Chrome no longer performs online OCSP checks as a default part of validation, and it has been tightening OCSP's remaining role, such as no longer counting OCSP-delivered timestamps toward its certificate transparency policy.
• The industry recommendation has moved on: prefer short-lived certificates or CRL-based revocation into browser updates rather than depending on an OCSP endpoint.

Because the classic per-connection OCSP soft-fails anyway, relying on stapling as your only revocation story is increasingly moot. The practical posture is to ship certificates that get automatic renewal (so expiry, not revocation, is the main lifecycle event), to keep quiet logs healthy, and to prefer CAs and certificate types whose revocation path browsers actually support. The certificate types article covers the certificate choices, and the renewal checklist keeps the more common expiry lifecycle under control.

What to do

There is no user action needed for OCSP on most modern stacks; browsers and CAs negotiate it. Server configs that offered an OCSP-stapling toggle still exist, and enabling it where the CA still publishes responses is harmless. The durable changes are to treat certificate expiry and renewal automation as the real maintenance (see renewal checklist), to understand how handshake negotiation works (how SSL works), and to recognise that revocation checking now lives mostly in the browser and the CA's issuance choices rather than in a server header. The certificate transparency logs article shows the parallel public ledger that gives visibility into misused certificates.