How do you safely roll out OCSP Must-Staple, given that misconfiguration hard-fails the site?

How do you safely roll out OCSP Must-Staple, given that misconfiguration hard-fails the site?

Must-Staple (RFC 7633, the TLS Feature extension) embeds a flag in the certificate requiring the server to staple a valid OCSP response; supporting clients hard-fail the connection if it is missing. That converts a soft revocation-check failure into a site outage. Cautious rollout.

— Get stapling rock-solid first without Must-Staple. Run weeks confirming -status always returns a verified response across reloads and responder outages.
— Add a stapling self-warm cron so the response cache is never empty when a client connects, eliminating the first-request gap.
— Plan for responder downtime: if your CA's OCSP responder is unreachable when the staple expires, Must-Staple clients will reject you. Choose a CA with a reliable responder and short renewal cadence.
— Only then request a cert carrying the Must-Staple extension, and stage it on a canary host before the fleet.
— Test hard-fail behavior deliberately by simulating a missing staple and confirming the client refuses, proving the protection works.

Evidence vs. speculation: Must-Staple's benefit (closing the revocation soft-fail gap) is real, but so is its outage mode.

Further reading: RFC 7633; RFC 6961 (multiple OCSP responses).

Bottom line: earn flawless stapling before opting into a flag that hard-fails when stapling lapses.