OCSP Stapling & Must-Staple Lab
Revoking a compromised certificate is supposed to make clients stop trusting it. In practice it often does not — because most clients soft-fail (they proceed when they cannot fetch the revocation status) and many non-browser clients never check at all. That soft-fail gap is exactly what a trusted-CA compromise exposes. Work through how revocation really reaches clients — OCSP vs CRL, OCSP stapling (the server caches and staples the status into the handshake), and OCSP Must-Staple (hard-fail if the staple is missing) — then toggle your own setup and see the residual revocation-trust risk, with the gaps ranked. The honest conclusion is that short-lived certificates and Must-Staple, not revocation alone, are what close the gap. Nothing is uploaded; no live certificate is checked.
Toggle your setup
Residual risk 100/100. With soft-fail clients and long-lived certs, revoking a compromised certificate may change almost nothing in practice. Start with short-lived certificates and stapling.
The soft-fail gap
This is the gap the eMudhra-style incident exposed: most clients that do check revocation soft-fail — if the status cannot be fetched they proceed as if valid — and many non-browser clients do not check at all. So revoking a certificate often does not stop a client from trusting it. Must-Staple (hard-fail) and short-lived certs are the two real answers.
Prioritised gaps
Highest-impact revocation controls you have not enabled, most impactful first.
- Short-lived certificates · +35 assurance
Move toward short-lived, automated certificates (ACME). This is the most robust mitigation because it does not depend on client revocation behaviour at all — the trust window simply expires.
- OCSP Must-Staple on certificates · +28 assurance
Consider Must-Staple on high-value certificates to close the soft-fail gap — but only alongside reliable stapling and monitoring, or you risk self-inflicted outages.
- OCSP stapling enabled · +22 assurance
Enable OCSP stapling on your TLS terminators so clients receive a fresh revocation status in the handshake instead of making their own OCSP call (or skipping the check entirely).
- CRL published & current · +9 assurance
Ensure CRLs are published and current as a fallback and to feed browser aggregate-revocation programs (Mozilla CRLite, Chrome CRLSets).
- Stapling is monitored · +6 assurance
Monitor that a valid, unexpired OCSP response is really being stapled; silent stapling failures are common and, with Must-Staple, cause outages.
OCSP, CRL, stapling and Must-Staple at a glance
| Mechanism | How it works | The gap |
|---|---|---|
| CRL | A signed list of revoked serials the client downloads and caches. | Large and slow to propagate; many non-browser clients never fetch it. Browsers now use aggregated forms (CRLite, CRLSets). |
| OCSP (client-queried) | The client asks the CA about one certificate at connection time. | Leaks browsing to the CA, adds latency, and almost universally soft-fails — if the CA is unreachable the client just proceeds. |
| OCSP stapling | The server fetches and caches the OCSP response and staples it into the handshake. | Fixes privacy and latency, but a soft-fail client still proceeds when no staple is present. |
| OCSP Must-Staple | The certificate requires a stapled response; conforming clients hard-fail without one. | Closes the soft-fail gap, but needs reliable stapling + monitoring or it causes outages; client/CA support is uneven. |
Educational — general guidance, not legal/compliance advice. This is a simplified teaching model of revocation assurance, not a measurement of any real deployment. The point weights are a transparent heuristic for which controls reduce revocation-trust risk most, shown so you can adjust them. This tool makes no network calls, checks no live certificate, and runs entirely in your browser — nothing is uploaded. Named mechanisms (OCSP, CRL, OCSP stapling, OCSP Must-Staple, CRLite, CRLSets, ACME) are referenced for orientation only.
What this lab is
- A free, 100% in-browser explainer and model for certificate revocation: toggle your setup (OCSP stapling, OCSP Must-Staple, CRL, short-lived certs, stapling monitoring) and see the residual revocation-trust risk with a prioritised gap list.
- OCSP stapling means the server fetches and caches the OCSP response and staples it into the TLS handshake — a privacy and latency win over the client asking the CA itself.
- OCSP Must-Staple hard-fails a connection when no stapled response is present, closing the soft-fail gap — but only if stapling is reliable and monitored, or it causes self-inflicted outages.
- The soft-fail gap is what the eMudhra-style incident exposed: most clients that check revocation proceed anyway when the status cannot be fetched, and many non-browser clients do not check at all — so a revoked certificate often stays trusted.
- Short-lived certificates are the most robust mitigation because they bound the exposure window regardless of whether any client checks revocation. Educational — nothing is uploaded, no live certificate is checked.
Why this matters
Revocation is the mechanism that is supposed to save you when a certificate — or the CA that issued it — goes bad. But revocation only helps clients that actually consume it, and the dominant behaviour is soft-fail: if the client cannot reach the OCSP responder or download the CRL, it assumes the certificate is valid and connects. An attacker who can block the revocation lookup — or simply a client that never checks, like a script running curl against a static bundle — keeps trusting a revoked certificate. This is the gap a trusted-CA compromise exposes: the CA can be distrusted, but whether that distrust reaches every client quickly is a different question.
OCSP stapling improves delivery — the server fetches and caches the signed status and staples it into the handshake, so clients get a fresh answer without phoning the CA — but on its own it does not force a soft-fail client to care. OCSP Must-Staple does: it tells conforming clients to refuse the connection if no valid staple is present. The catch, shown honestly in the model above, is that Must-Staple without reliable, monitored stapling turns a responder outage into a site outage. The most robust control is structural: short-lived certificates bound the exposure window regardless of client behaviour, which is why the industry is moving toward much shorter certificate lifetimes with ACME automation. Treat plain revocation as advisory, enforce it with Must-Staple where you can, and shrink the window with short-lived certs. This is an educational model, not a measurement of any real deployment, and not compliance advice.
Frequently asked questions
What is the difference between OCSP and CRL?
Both answer "has this certificate been revoked?" A CRL (Certificate Revocation List) is a signed list of revoked certificate serial numbers that a client downloads and caches — it is comprehensive but large and slow to propagate, and many clients never fetch it. OCSP (Online Certificate Status Protocol) lets a client ask the CA about one specific certificate at connection time — smaller, but it leaks which sites you visit to the CA, adds latency, and almost universally soft-fails. Modern browsers have largely moved to aggregated revocation (Mozilla CRLite, Chrome CRLSets) pushed to the browser, rather than live per-connection OCSP.
What is OCSP stapling and why is it better?
With plain OCSP, every client contacts the CA to check your certificate, which is slow and tells the CA who is visiting you. OCSP stapling flips this: the server fetches the OCSP response for its own certificate, caches it, and "staples" that signed, time-stamped response directly into the TLS handshake. The client gets a fresh revocation status without contacting the CA at all — better privacy, lower latency, and less load on the CA. The catch is that stapling alone does not force anything: a soft-fail client that receives no staple will still proceed.
What is OCSP Must-Staple and what is the soft-fail gap it addresses?
Most clients do revocation checking on a soft-fail basis: if they cannot retrieve the revocation status (CA unreachable, response missing), they assume the certificate is fine and connect anyway. That means an attacker who can block the revocation check can keep using a revoked certificate — and many non-browser clients (curl against a static bundle, language trust stores, appliances) do not check revocation at all. OCSP Must-Staple is a flag baked into the certificate (the TLS status_request feature extension) that tells conforming clients to HARD-FAIL if no valid stapled OCSP response is present. It closes the soft-fail gap — but it is only safe if your stapling is reliable and monitored, because a stapling failure then becomes a hard outage. Client and CA support for Must-Staple is also uneven.
If revocation soft-fails, what actually protects me?
Two things. First, short-lived certificates: if a certificate is only valid for days, the window in which a compromised or mis-issued one can be abused is naturally small, regardless of whether any client checks revocation — which is why the industry is moving toward much shorter certificate lifetimes with automated (ACME) renewal. Second, Must-Staple (with reliable, monitored stapling) for the clients that support it. Plain revocation — CRL or soft-fail OCSP — is best thought of as advisory: useful, consumed well by browser aggregate-revocation programs, but not something to rely on as your only control. This tool is an educational model to make those trade-offs concrete; it checks no live certificate and is not compliance advice.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.Educational — general guidance, not legal/compliance advice.