The Online Certificate Status Protocol (RFC 6960) lets a TLS client ask a CA's responder whether a specific certificate has been revoked, without downloading a full Certificate Revocation List. It became the standard real-time revocation mechanism of the web PKI era, though its limitations have pushed the industry toward alternatives such as CRLSets and short-lived certificates.
When a browser connects to a server and receives its certificate chain, it can send an OCSP request to the URL embedded in the certificate's Authority Information Access extension. The CA's OCSP responder replies with a signed status: good, revoked, or unknown. The response is signed by the CA (or a designated responder key) so the client can verify its authenticity without a live CA connection.
OCSP improves on Certificate Revocation Lists (CRLs) in two ways: responses are per-certificate rather than full list downloads, and the protocol is designed for low-latency queries. However, both mechanisms share the same fundamental weakness: browsers treat failures as non-fatal.
Browsers that perform live OCSP lookups have historically soft-failed: if the responder is unreachable or returns an error — due to network issues, responder outage, or an attacker blocking the request — the connection proceeds anyway. This behavior was a deliberate design choice: a strict failure would let any network path between the user and the OCSP server become a denial-of-service vector against every site whose certificate routes through that responder. In practice, Chrome and Edge do not make live OCSP queries at all — they ship aggregated revocation sets (such as CRLSets) — and Firefox has been retiring live leaf-certificate OCSP checks.
The consequence is that OCSP has provided weak real-time revocation guarantees in practice. An attacker who can replay a stolen certificate and block OCSP traffic can bypass revocation checks entirely.
OCSP stapling addresses both the privacy and latency problems of client-side OCSP. Instead of the browser querying the CA's responder directly, the web server periodically fetches a signed OCSP response and caches it. During the TLS handshake the server delivers ("staples") this cached response to the client via the TLS status_request extension.
The benefits are significant:
OCSP stapling is still subject to the soft-fail problem unless the certificate includes the must-staple extension (formally TLS Feature extension with the status_request value). A must-staple certificate signals that clients should hard-fail if no valid staple is presented — closing the soft-fail loophole at the cost of requiring servers to maintain a fresh staple at all times.
The fundamental tension in revocation is that no real-time check is perfectly reliable. The industry response has been to reduce certificate lifetimes so that compromised certs expire quickly rather than relying on revocation to invalidate them. Let's Encrypt has moved away from OCSP toward CRL-based revocation as its primary mechanism, reflecting broader recognition that aggregated CRL distribution at scale is more tractable than per-certificate OCSP queries. The direction across the ecosystem is toward certificates short enough that revocation becomes less critical.
Inspect certificate details with the TLS tool
Open TLS Inspector