The Online Certificate Status Protocol (OCSP), defined in RFC 6960, was the response to a problem nobody could solve cleanly. Certificate Revocation Lists (CRLs) — the original 1990s mechanism — required browsers to download enormous, ever-growing lists of revoked certificates. By the late 2000s some CA CRLs were tens of megabytes, downloaded on every cold connection. OCSP replaced the bulk download with a single query: is this one certificate still valid?
That fixed the size problem. It introduced a different one: every time you visit a TLS-protected website, your browser tells the certificate authority you're about to do it.
How Vanilla OCSP Works
When your browser receives a TLS certificate during the handshake, it parses an OCSP responder URL from the certificate's Authority Information Access extension. The browser then makes an HTTP request to that responder containing the certificate's serial number, asking for a signed status response: good, revoked, or unknown.
The response is a small CMS-signed structure containing the status, the time it was produced, and a validity window (typically a few days). The browser caches the response and proceeds with the TLS connection.
The OCSP responder learns: which CA-issued certificate you're about to connect to, your IP address, and approximately when you connected. Aggregated, that's a complete record of every HTTPS site you visit, served by an external party you have no business relationship with.
There is also a reliability problem. If the OCSP responder is slow or unreachable, the browser has a choice: hard-fail (refuse the connection — breaks the user experience constantly) or soft-fail (proceed without a check — defeats the purpose of revocation). Almost every major browser chose soft-fail. Which means in practice, an attacker who can block OCSP traffic from your network can use a revoked certificate against you with no warning at all.
What Stapling Changes
OCSP stapling — defined in RFC 6066 §8 as the status_request TLS extension — flips the direction of the OCSP query. Instead of the client asking the CA, the server asks the CA, periodically, on the client's behalf. The server then attaches ("staples") the signed OCSP response to its TLS handshake.
The client gets the same revocation information, signed by the same CA, but the CA never sees the client. The CA only ever talks to the server — which is a relationship the CA already has, since the CA issued the server's certificate.
Operationally:
- The web server fetches a fresh OCSP response from its CA every few hours.
- The server caches the response (along with its CA signature and timestamp).
- On every TLS handshake, if the client advertised the
status_requestextension, the server includes the cached OCSP response in its handshake messages. - The client verifies the OCSP signature using the CA's known public key. No external query needed.
Why Stapling Alone Isn't Enough
Stapling solves the privacy and latency problems, but it doesn't solve the soft-fail problem. A man-in-the-middle attacker who has stolen the private key for a revoked certificate can simply omit the stapled response. The client has no way to know whether the server "couldn't get an OCSP response" or "deliberately skipped it because the certificate is revoked." Soft-fail says: proceed anyway.
The fix is a small X.509 certificate extension called OCSP Must-Staple, defined in RFC 7633 (OID 1.3.6.1.5.5.7.1.24). When a certificate carries this extension, browsers treat the absence of a stapled OCSP response as a hard failure. Revocation actually works as intended.
Must-Staple is a one-way commitment. Once you've issued a certificate with the extension, your servers must staple — or your site goes down. That operational risk is the main reason adoption has been slow.
What Different Browsers Actually Do
The PKI ecosystem in 2026 is far from uniform on revocation. The major browsers have made different bets:
| Browser | Default Behavior |
|---|---|
| Chrome / Edge (Chromium) | Does not perform online OCSP checks for non-EV certificates. Uses CRLSets — a curated, pushed list of high-impact revocations — instead. Honors stapled OCSP if present. |
| Firefox | Performs online OCSP checks by default for end-entity certificates and honors stapled responses preferentially. Hard-fails on Must-Staple. |
| Safari | Apple removed online OCSP fetching from Safari in 2021 (macOS 11, iOS 14) following the trustd outage incident. Honors stapling. |
Chrome's CRLSet approach is essentially a curated CRL with a few thousand certificates, pushed via the browser's update channel. It's pragmatic but incomplete — most revocations don't make the list. Apple's removal of online OCSP was a privacy and reliability decision after a centralized OCSP outage briefly made every macOS application slow to launch.
Short-Lived Certificates: The Other Answer
The CA/Browser Forum has been steadily reducing maximum certificate lifetimes: 825 days in 2018, 398 days in 2020, 47 days by 2029 per the most recent ballot. The reasoning is straightforward — if certificates only live a few weeks, the cost of waiting for natural expiry instead of revoking is much lower. Revocation becomes less load-bearing, and the whole OCSP problem gets smaller by attrition.
Let's Encrypt has issued 90-day certificates since launch, and ACME automation made short lifetimes operationally trivial. A 47-day maximum changes the cost-benefit of stapling: it's still useful for the cases where a certificate must be killed early, but the steady-state revocation rate becomes very low.
Deploying Stapling Properly
If you operate a TLS server, three rules cover most of the operational risk:
- Cache aggressively, refresh proactively. Fetch a new OCSP response from your CA well before the current one expires — at least daily. Don't let your stapled response go stale just because the responder happened to be down at refresh time.
- Don't issue Must-Staple certificates until your refresh tooling is solid. Must-Staple converts every stapling failure into a site outage. That's the right behavior for security, but it's a real availability commitment.
- Honor the CT log entries. Stapling tells clients about revocation; CT tells the world about issuance. They solve different parts of the same PKI trust problem.
Where This Fits in a Threat Model
OCSP stapling matters most when:
- You're operating infrastructure where a key compromise needs to be communicated to clients before the natural certificate expiry.
- Your users have strict latency requirements — stapling eliminates the round-trip to the CA on every cold TLS connection.
- You care about privacy from third parties — every OCSP query is a record of a TLS connection. Stapling closes that channel.
For email infrastructure (where MTA-STS and TLS-RPT already raise the bar on transport security), and for any privacy-critical service, stapling should be on by default. It's a small operational tax for a meaningful improvement in revocation hygiene and a real reduction in third-party visibility.
Haven's infrastructure staples on all public endpoints and treats stapling failures as alerting conditions, not warnings. The point of revocation is to fail closed when it should.