OCSP Must-Staple Checker

Check if certificate has OCSP must-staple extension

About OCSP Must-Staple

OCSP Must-Staple is a certificate extension (defined in RFC 7633) that tells clients the server must provide an OCSP stapled response during the TLS handshake. This ensures certificate revocation status is checked in real-time rather than relying on CRLs or client-initiated OCSP requests, which can be privacy-invasive and slow. Our Must-Staple Checker verifies whether a certificate includes this critical extension.

How to Use

Enter the domain name of the server you want to check.
Adjust the port number if the service runs on a non-standard port.
Click Check to fetch the certificate and analyze its extensions.
Review the result to see if the Must-Staple extension is present and whether OCSP stapling is properly configured.

Use Cases

Certificate Procurement: Verify that newly issued certificates include the Must-Staple extension for enhanced security.
Server Hardening: Ensure your servers are configured to provide OCSP stapled responses when the certificate requires it.
Security Auditing: Check that all certificates in your infrastructure comply with OCSP Must-Staple requirements.
Browser Compatibility: Confirm that Must-Staple certificates are correctly served to avoid browser warnings.

Frequently Asked Questions

OCSP Must-Staple is a TLS certificate extension that requires the server to provide an OCSP response (staple) during the TLS handshake. Without it, the client must fetch revocation status separately, which can fail silently or leak privacy.

Regular OCSP stapling is optional and configured server-side. Must-Staple is a certificate extension that makes stapling mandatory. Browsers that support Must-Staple will reject connections if the server fails to provide a valid OCSP staple.

Yes, if your server infrastructure supports OCSP stapling properly. Must-Staple improves security by ensuring revocation status is always checked. However, ensure your servers are configured correctly, or clients may fail to connect.

It makes revocation non-optional. A certificate carrying the extension tells clients: if you cannot obtain a revocation response for this certificate, reject it rather than proceed on trust alone. That closes the window where a stolen key works until the authority publishes a revocation, because clients refuse to fall back to plain trust.

Because it inverts the failure mode. Without the promise, a server that cannot staple still works — clients fetch the revocation status themselves and carry on. With the promise, the same server eventually gets its certificate rejected, because the client is required to fail closed. So must-staple is only safe once stapling is reliably working, and never a change to make without also fixing revocation serving.

If you control the full serving path and staple reliably, yes — it is a real improvement and browsers have supported it for years. If TLS terminates at a CDN or load balancer you do not control, check that the edge staples on your behalf first, because the certificate will be rejected if it does not. Treat it as a change with a testing step, not a checkbox to tick during issuance.

Yes, significantly, and this surprises people. A must-staple certificate cannot be silently replaced by a client fetching a new one the way a non-must-staple certificate can, so its lifetime is heavily curtailed — currently around 90 days regardless of what the authority would otherwise issue. That makes renewal automation mandatory rather than advisable, since there is no room for a long manual turnaround.

Mostly caution. The mechanism is sound and widely supported, but it turns any stapling failure into an outage, and organisations reasonably hesitate to adopt something where a misconfiguration takes the site down. Authorities also offer it less prominently than the default product. Adoption is growing as stapling becomes standard practice, and the barrier is now operational confidence rather than technical support.

What the Checker Looks For

Must-staple is a certificate extension making a promise about behaviour when revocation cannot be checked. This page reads the extension and reports whether the promise is present.

1Retrieve the certificate and look for the TLS Feature extension carrying the must-staple status request. Presence or absence is reported plainly, since an absent extension is the normal state for most certificates.
2Explain what the promise actually commits a server to. If a must-staple certificate cannot serve a revocation response, clients are required to reject it — which is exactly what makes it valuable, and exactly what makes it dangerous if the server is later misconfigured.
3Pair the finding with stapling support. A must-staple certificate without working stapling will eventually be rejected by clients, so the two checks belong together on a renewal checklist rather than being treated as independent.

This page reads the extension from the certificate as served. Whether the server actually staples a response at runtime is a separate question the stapling page addresses — and one that matters just as much once must-staple is present.

Tips & Best Practices

•Must-Staple requires OCSP stapling to be enabled on your server
•Ensure your server can fetch fresh OCSP responses before enabling Must-Staple
•Test OCSP stapling functionality before deploying Must-Staple certificates
•Monitor OCSP response freshness to avoid serving stale responses

Technical Details

Extension: TLS Feature extension (RFC 6962) detection
OCSP: Online Certificate Status Protocol integration requirements
Validation: Certificate extension analysis and configuration verification
Servers: Nginx, Apache, and HAProxy OCSP stapling support