OCSP Must-Staple is a certificate extension that tells a connecting client: this certificate must be presented with a stapled OCSP response, and if it isn't, reject the connection rather than falling back to a plain, unstapled check. It's a stricter variant of standard OCSP stapling, which our dedicated guide covers as an optional server-side optimization — Must-Staple removes the "optional" part.
The specific problem it was designed to solve
Standard OCSP stapling has a soft-fail weakness: if a server simply doesn't staple a response — misconfigured, or an attacker actively stripping it — most clients fall back to either skipping the revocation check entirely or attempting their own separate OCSP query, which itself can be blocked by a network-level attacker. Must-Staple closes this gap by making the absence of a stapled response itself a hard failure, rather than a silent fallback to weaker or no revocation checking.
How it's in practice requested and applied
Must-Staple is requested at CSR generation time via the tlsfeature extension, specifying the OCSP status request feature. Once a CA includes this extension in the issued certificate, every client that respects Must-Staple will refuse the connection if your server fails to staple a current OCSP response alongside it — which raises the operational stakes: your OCSP stapling configuration now has to work reliably, since a failure no longer degrades gracefully.
Why adoption never became widespread
The strict, no-fallback behavior that makes Must-Staple more secure is also exactly what makes it operationally risky: if your OCSP responder is ever briefly unreachable, or your server's stapling cache fails to refresh in time, visitors using a Must-Staple-respecting client see a hard connection failure instead of a degraded-but-working connection. For most site operators, this risk profile outweighs the security benefit, especially since not all major browsers strictly enforce Must-Staple in the first place — the extension is honored inconsistently across clients, further limiting its practical benefit relative to its operational risk.
Where it's in fact used today
Must-Staple sees more real use in narrower, higher-assurance contexts — specific enterprise deployments, some certificate pinning setups, and environments where the operators have both a strong reason to want hard-fail revocation checking and the operational maturity to keep stapling reliably working. For a typical website, standard (non-Must-Staple) OCSP stapling remains the more practical default.
Checking if a certificate has this extension set
openssl x509 -in certificate.crt -noout -text | grep -A1 "TLS Feature"If present, this confirms the certificate carries the Must-Staple flag — worth checking specifically if you're troubleshooting a connection failure that seems tied to OCSP stapling rather than a certificate or chain issue, since a Must-Staple certificate with broken stapling produces a harder, less forgiving failure than the same stapling problem would on a standard certificate.
See RFC 6960, the OCSP specification.
Loading comments…