<b>What actually happens to a browser when OCSP Must-Staple is set but the staple is missing?</b>

<b>What actually happens to a browser when OCSP Must-Staple is set but the staple is missing?</b>

This exposes the gap between revocation theory and deployed reality.

The Online Certificate Status Protocol (OCSP, RFC 6960) lets a client ask a Certificate Authority (CA) whether a certificate is revoked. Plain OCSP has two flaws: it leaks the user's browsing to the CA, and clients historically soft-fail — if the OCSP responder is unreachable, they proceed as if the cert were valid. Adam Langley's 2014 analysis called revocation checking effectively useless for this reason.

OCSP stapling (the certificate_status TLS extension, RFC 6066) fixes the privacy leak: the server fetches a signed OCSP response and attaches it to the handshake. But stapling is optional, so a man-in-the-middle holding a revoked cert can simply omit the staple, and the soft-failing client accepts it.

Must-Staple (RFC 7633, the TLS Feature extension with id-pe-tlsfeature) closes that hole. It is a bit baked into the certificate at issuance asserting "a valid staple will always be present." A conforming client that sees this extension and receives no staple must hard-fail the connection.

The catch: adoption is thin, and a misconfigured server that stops stapling bricks its own site. That fragility is why Must-Staple never went mainstream, and why CAs are pivoting to short-lived certificates instead.

Further reading: RFC 6960, RFC 6066 §8, RFC 7633; Langley, "Revocation still doesn't work" (2014).

Bottom line: Must-Staple makes revocation enforceable but couples uptime to staple availability — most operators chose shorter certs over that risk.