OCSP Must-Staple · Web Quality Index

TL;DR: Must-Staple is a cert extension that tells browsers “refuse to connect if you don’t see a fresh stapled OCSP response.” It closes the soft-fail hole that lets network attackers suppress revocation checks. It also turns any stapling hiccup into a hard outage. Most operators ship OCSP stapling (WEBQ-91) and stop there — Must-Staple is for teams who have proven their stapling never blinks.

What is it?

Before Must-Staple makes sense, you have to understand why OCSP is weakly enforced today.

OCSP is the protocol browsers use to ask “has this certificate been revoked?” Either the browser asks the CA’s OCSP responder directly, or — much better — the server pre-fetches the answer and staples it into the TLS handshake. Either way, the browser gets back a short-lived signed statement: “as of N hours ago, serial X is still valid.”

But what happens when the OCSP responder is unreachable, the response is missing, or a network attacker drops the request on the floor?

In practice, browsers default to soft-fail: trust the cert anyway. Hard-failing would mean every CA outage takes down half the web, and the major browser vendors decided the cure was worse than the disease. The downside is that revocation is weakly enforceable. An attacker who has stolen a cert’s private key can suppress the OCSP response and most browsers will silently accept the connection.

Must-Staple flips this default for the certs that opt into it. The cert itself carries a small extension — the TLS Feature extension defined in RFC 7633, with OID 1.3.6.1.5.5.7.1.24 and a value of 5 (status_request) — that tells compatible clients:

If you don’t see a fresh stapled OCSP response in the handshake, refuse to connect. Assume the worst.

It’s a one-bit promise baked into the cert at issuance time. The browser sees Must-Staple in the cert, demands a staple, and hard-fails if one isn’t there. Soft-fail is no longer an option for that cert.

Why does it matter?

Must-Staple makes revocation actually mean something for the certs that carry it. Without it, the chain of attacks looks like:

Attacker steals your private key.
You discover the breach and ask your CA to revoke the cert.
CA publishes the revocation in OCSP.
Attacker MITMs a victim’s connection and presents the stolen cert.
Attacker also blocks the victim’s path to the CA’s OCSP responder.
Browser falls back to soft-fail and trusts the cert. Game over.

With Must-Staple, step 6 changes: the browser sees the Must-Staple extension, demands a stapled response, and refuses to connect because the attacker can’t produce a fresh one signed by the CA. The MITM fails closed. That’s the whole point.

The catch is that Must-Staple is a strict ratchet pointed at your own operations. The same hard-fail behavior that stops the attacker also fires when you have a problem:

Your CA’s OCSP responder has an outage and your server can’t refresh its staple before the previous one expires.
A new server in the load balancer pool ships without stapling configured.
A resolver directive goes missing in an Nginx config refactor.
A staple is cached past its nextUpdate time.

In all of those cases, every visitor with a Must-Staple-aware browser gets a hard connection failure. That’s why a Must-Staple cert is only as reliable as your stapling reliability — and most operators have not proven theirs to that standard.

Real-world analogy

Picture the bouncer from the OCSP stapling explainer.

OCSP without Must-Staple is the bouncer saying: “I’ll try to call the DMV. If they don’t pick up I’ll just let you in — better than holding up the line.” Convenient, but it means anyone who can jam the bouncer’s phone gets a free pass.

OCSP with Must-Staple is the bouncer saying: “I called the DMV four hours ago and have a notarized note from them confirming this license is current. If you can’t show me the current note, I refuse to let you in — even if you have the license itself.” Strict. But it rules out a whole class of network-attacker shenanigans where the attacker stole a license a week ago and is hoping nobody can reach the DMV to check.

The trade-off shows up the day the DMV’s switchboard is down and the bouncer can’t refresh the note in time. Without Must-Staple: line keeps moving. With Must-Staple: nobody gets in until the note is current again.

A note on adoption

Must-Staple deployment in the wild is low and has stayed low for years. Three reasons:

Most CAs don’t issue Must-Staple by default. You have to opt in at issuance time. Let’s Encrypt supported it via a --must-staple flag, DigiCert and Sectigo support it via order-form or API toggle, but none of them make it the default. That’s a friction tax against accidental adoption.

Operators rightly fear the hard-fail risk. The math doesn’t favor the average team. The attack Must-Staple prevents (network attacker suppressing OCSP after a key compromise) is rare and assumes a specific, sophisticated adversary. The failure mode it adds (any stapling hiccup becomes an outage) hits the operator on every CA incident. Most teams correctly conclude they’d rather take the small revocation-weakness risk than the operational risk.

Modern alternatives reduce the urgency. Short certificate lifetimes (WEBQ-95) shrink the window in which a stolen cert is useful — a 90-day Let’s Encrypt cert that gets revoked at day 30 only had 60 days of usefulness left anyway. Mozilla’s CRLite pushes a compressed bloom-filter of every revoked cert directly to Firefox clients, so the browser knows about revocations without ever talking to OCSP. Together, these have made the soft-fail problem less existential than it looked in 2015 when Must-Staple was new.

The realistic deployment pattern: enable stapling (WEBQ-91), watch it for a few months, keep your cert lifetimes short, and skip Must-Staple unless you have a specific threat model that justifies the operational tax.

How WQI measures this

We grade Must-Staple as factor WEBQ-96 in the Security category. The data source is two parallel checks combined into one score:

Cert extension scan. We pull the leaf certificate from the TLS handshake and look for the TLS Feature extension at OID 1.3.6.1.5.5.7.1.24. If present and asserting feature 5 (status_request), the cert is Must-Staple.
Stapling check. We re-use the WEBQ-91 signal — did the server actually staple an OCSP response in this handshake?

The two signals are crossed into a four-cell scoring matrix:

Must-Staple	Stapling	Score	What it means
Present	Yes	Pass (100)	Cert asserts the constraint and server meets it. Strongest possible position.
Present	No	Warn (60)	Cert asserts the constraint, server doesn’t meet it. Broken — Must-Staple-aware clients are hard-failing on you right now.
Absent	Yes	Warn (30)	Server staples but cert doesn’t require it. Good operationally; doesn’t close the soft-fail hole.
Absent	No	Fail (0)	Soft-fail vulnerability is wide open.

The warn=60 case is the dangerous one — a Must-Staple cert deployed to a server that isn’t stapling means every Must-Staple-aware browser is already refusing the connection. That’s an outage you may not have noticed because most monitoring doesn’t simulate Must-Staple-aware clients.

What good looks like

For most operators, the answer is:

WEBQ-91 (stapling): Pass. Always. There’s no good reason to skip stapling on any modern web server.
WEBQ-96 (Must-Staple): Warn (30). Server staples without Must-Staple. This is the safe default. You get the privacy and performance wins of stapling without the hard-fail blast radius.

Only push to WEBQ-96 Pass (100) if you’ve proven your stapling reliability across at least one CA-responder incident. That means: real monitoring of staple freshness, alerting before the staple expires, automated re-fetch with retries, and tested recovery from your CA’s last outage. If you can’t point at all four of those, stay at WEBQ-96 Warn (30).

How to fix it (only if you’re sure)

If you’re sure you want Must-Staple, the order is prove stapling first, then request Must-Staple at issuance.

Step 1 — prove stapling. Run OCSP stapling in production for at least a few months. Add monitoring on thisUpdate freshness. Run a fire drill where you simulate a CA-responder outage in staging and verify your server keeps serving stapled responses until they’re genuinely expired.

Step 2 — request Must-Staple from your CA. This is a one-time flag at issuance time:

Let’s Encrypt — the certbot --must-staple flag has historically worked, but Let’s Encrypt has signaled deprecation of the option. Check the current Let’s Encrypt documentation before relying on it.
DigiCert / Sectigo — supported via the order form or API request flag. Talk to your account team.
Other ACME CAs — check the CA’s own documentation. The OID is standard but support is per-CA.

Step 3 — verify after deploy. The cert dump should show the TLS Feature extension:

openssl x509 -in cert.pem -noout -text \
  | grep -A 1 "TLS Feature\|1.3.6.1.5.5.7.1.24"

You’re looking for a line like TLS Feature: status_request. If you see it, the cert carries Must-Staple and your server must also be stapling — verify with the WEBQ-91 stapling check from the stapling explainer.

Step 4 — do not roll Must-Staple cert to production until staging has run a Must-Staple-aware browser through a simulated CA-responder outage. This is the test most teams skip. The cert works fine until the day it doesn’t, and then the failure mode is hard-down for every visitor at once.

Common pitfalls

Must-Staple cert deployed to a server without stapling configured. Instant outage. The most common deployment mistake — someone enables Must-Staple at issuance, forgets the server-side config, and ships the cert. Pre-deploy verification with openssl s_client -status would catch this in seconds.
Load balancers that don’t propagate stapled responses. Some L7 proxies terminate TLS, fetch their own staple, and cache it. Others pass through the staple from the origin. Mismatch between expected and actual behavior here breaks Must-Staple silently.
Staple expiring mid-handshake during DNS or routing flaps. If your server can’t reach the CA to refresh the staple before the current one’s nextUpdate passes, Must-Staple-aware clients hard-fail. Allow extra headroom on refresh, not the bare minimum.
CDN in front, origin Must-Staple cert behind. Cloudflare and similar CDNs handle stapling on their side and present their own cert to visitors. Your origin’s Must-Staple status is invisible to visitors and the CDN’s stapling is what matters. Don’t enable Must-Staple on origin certs that visitors never see directly.