OCSP Must-Staple or live with soft-fail: which closes the revocation hole, and at what risk?

OCSP Must-Staple or live with soft-fail: which closes the revocation hole, and at what risk?

Why does revocation so often fail to protect anyone, and can a certificate extension fix it? The failure is soft-fail; the candidate fix is Must-Staple, and it is a sharp tradeoff.

Under soft-fail, when a client cannot reach revocation status it assumes the certificate is valid. An attacker who blocks the OCSP query defeats revocation entirely. Must-Staple (RFC 7633, the TLS Feature extension) embeds a flag in the certificate telling clients to require a valid stapled OCSP response — turning soft-fail into hard-fail for that certificate.

The security gain is real: a revoked certificate can no longer slip through a blocked responder. The operational risk is equally real. If your stapling pipeline breaks — the server fails to fetch or cache a fresh response — clients now hard-fail and your site goes dark. You have traded a security gap for an availability dependency.

— Adopt Must-Staple only with monitored, redundant stapling.
— Alert on stale OCSP responses well before expiry.
— Skip it if your stapling reliability is uncertain.

Further reading: RFC 7633; RFC 6066 §8.

Bottom line: Must-Staple genuinely closes the soft-fail hole, but converts a stapling outage into a hard outage — only worth it with airtight stapling operations.