What OCSP is

OCSP (Online Certificate Status Protocol) is the real-time counterpart to CRLs for certificate revocation. Instead of the CA publishing a bulk list of every revoked certificate, the relying party asks about one certificate at a time: "is serial=0x1234abcd revoked?" The CA (or a delegated OCSP responder) returns a signed response with the certificate's status.

The protocol is defined in RFC 6960, with the newer "OCSP must-staple" extension in RFC 7633.

How it works

The client has a certificate to validate. It extracts the OCSP responder URL from the Authority Information Access (AIA) extension of the certificate.
The client builds an OCSP request. The request identifies the certificate by issuer name hash, issuer public key hash, and serial number.
The client POSTs or GETs the request to the OCSP responder URL.
The responder signs and returns the response. Status is one of: good, revoked, or unknown. The response carries a thisUpdate and nextUpdate for caching.
The client verifies the response signature against the OCSP responder's certificate and acts accordingly.

What OCSP does well

Freshness. The CA can reflect a revocation in OCSP within minutes — much faster than CRL republication cadence.
Small response size. A few hundred bytes per response, regardless of how many certificates the CA has issued.
Scalable per-client. A client validating 10,000 certs makes 10,000 small queries, not one giant CRL fetch.

Where OCSP breaks

Server-side load. Every TLS handshake can trigger an OCSP query. For a high-traffic site, that's thousands of OCSP queries per second against the responder. Public CAs run global anycast OCSP infrastructure to cope.
Privacy leak. The CA sees every query — which identifies which relying parties are validating which certificates. This is a known privacy problem of OCSP as originally designed.
Latency. Each OCSP query adds a round-trip to the handshake. A client in Singapore validating a cert against an OCSP responder in Virginia adds 200+ ms per handshake.
Soft-fail. Most non-browser TLS clients treat an unreachable OCSP responder as "not revoked." This defeats the purpose of OCSP — a reachable DNS + a firewalled OCSP responder = successful revocation bypass.
Single point of failure. If the OCSP responder goes down and clients hard-fail, the entire fleet stops validating. If clients soft-fail, revocation stops working for the duration.

OCSP stapling

RFC 6066's status_request extension moves the OCSP query from the client to the server. The TLS server periodically fetches an OCSP response for its own certificate, caches it, and includes ("staples") it in every TLS handshake. Clients validate the stapled response without making their own OCSP query.

Why stapling matters

Zero client-side latency. The OCSP response arrives in the handshake.
No privacy leak. The CA only sees the server fetching for its own certificate, not every client validating.
Scales to the server. One fetch per server per cache interval, regardless of how many clients connect.
Supports hard-fail. Combined with Must-Staple, servers advertise that they will always provide a stapled response, and clients that see a certificate without one treat it as invalid.

Must-Staple (RFC 7633)

A certificate can carry the tls-feature extension with value status_request — the "Must-Staple" marker. A client that sees a Must-Staple certificate without a valid OCSP staple treats the certificate as invalid. This is the only widely-deployed hard-fail revocation mechanism that doesn't break on OCSP responder outages, because stapled responses are cached at the server.

OCSP vs CRL in practice

Dimension	OCSP	OCSP Stapling	CRL
Freshness	Minutes	Minutes (cache-dependent)	Hours to days
Client-side latency	+RTT	0	0 (cached)
Privacy	Poor	Good	Good
Server load	None	Low (periodic fetch)	Low (bulk publish)
Hard-fail available	Rare	Yes (Must-Staple)	Rare
Non-browser support	Universal	Server-side opt-in	Universal

See the CRL glossary entry and the CRL vs OCSP blog post for the full comparison.

Operational configuration (2026+)

For production TLS endpoints:

Enable OCSP stapling on every terminating server (nginx ssl_stapling on, HAProxy resolvers + ssl ocsp-responders, Envoy's ocsp_staple).
Set OCSP cache lifetime to 1-24 hours. Shorter is fresher; longer survives responder outages.
Add Must-Staple to new certificate profiles where client support allows it (most modern clients do).
Monitor stapled response freshness. Alert when a server's stapled response age exceeds its nextUpdate.

OCSP