OCSP Stapling Checker

Check if a domain supports OCSP stapling

Responder URL

Status

About OCSP Stapling Checker

OCSP stapling lets web servers cache and present the certificate revocation status during the TLS handshake, eliminating the need for browsers to contact the CA's OCSP responder directly. Our OCSP Stapling Checker tests whether a server supports this optimization and validates the OCSP response it provides.

How to Use

1Enter the domain name you want to test for OCSP stapling support.
2Click "Check" to connect and test the server's OCSP stapling configuration.
3Review the stapling status, responder URL, and OCSP response details.

Use Cases

•Verify OCSP stapling is properly configured on your web server
•Improve TLS handshake performance by enabling stapling
•Reduce load on CA OCSP responders for better scalability
•Audit server configuration for privacy-enhancing TLS features

Frequently Asked Questions

It improves privacy (browsers don't leak browsing history to CAs), speeds up TLS handshakes, and reduces the load on CA infrastructure. Without it, every visitor must contact the CA to verify revocation.

On Nginx add ssl_stapling on and ssl_stapling_verify on; on Apache set SSLUseStapling on and SSLOCSPEnable on. Both also need a properly configured certificate chain including intermediates, because the server cannot build a valid request without the issuer. It only applies to TLS 1.2 and later, since older protocols have no extension to carry the response. Verify it afterwards rather than assuming: the handshake should carry a stapled response, and a silent no-op is the usual outcome when the chain is incomplete.

The OCSP Must-Staple extension (TLS Feature) tells browsers they must refuse connection if the server doesn't provide a stapled OCSP response, making revocation checking mandatory.

Because it cannot be observed with the tools this server has. Stapling is the server sending an OCSP response inside the TLS handshake, and Python's TLS library exposes no way to see it. The previous version inferred it from the certificate advertising a responder URL, which nearly every public certificate does, so it reported enabled for almost every site. An honest not-detectable result is more useful than a pass that means nothing.

Connect with openssl s_client and the -status flag, then read the handshake output for a stapled certificate status block. It shows the responder's verdict, the times the response was produced and when it next refreshes. Absence of that block means no response was stapled. Doing it twice shows whether the cached response is being refreshed or is going stale.

The certificate's revocation state according to its issuer, asked at the moment you ran the check. A good status means the CA considers the certificate valid; revoked means someone reported it compromised and the CA acted. That is genuinely useful information, and unlike a stapling guess it comes from an authoritative answer rather than an inference from configuration.

Rarely, and it is often deliberate. Some authorities — Let's Encrypt among them — omit the AIA responder and rely on short certificate lifetimes and CRLs instead, so their certificates behave correctly while showing nothing here. A certificate with no responder is not necessarily weak; it means this particular revocation channel is not available for it, and the other page on this site covers the CRL path.

Because it saves your users a round trip to a third party on every connection. Without stapling, each client that wants to check revocation must reach the CA's responder separately, which is slow and leaks metadata about which sites they visit to the CA. Stapling moves that cost to the server, where the response is fetched once and reused across every visitor.

What This Page Measures

Two different things get confused under the name OCSP stapling, and only one of them is observable from outside. This page measures the one it can measure, and says so plainly.

1Read the certificate's responder URL from its Authority Information Access extension. Nearly every public certificate publishes one, which is why treating its presence as evidence of stapling produced a pass for almost every site — the responder existing says nothing about whether the server sends the response during the handshake.
2Query that responder directly and report what it actually answers about this certificate. The previous version returned a status of Good without contacting anyone; now the status comes from the responder, so it is a real revocation answer rather than an assumption.
3Report stapling as not detectable. Python's TLS library exposes no API for observing a stapled response, so claiming to test it would be claiming a measurement nobody made. The field exists and is always false, which is the honest answer.

To confirm stapling for real, connect with openssl s_client -status and look for the stapled certificate status in the handshake output. That is a direct observation of the server's behaviour rather than an inference from the certificate.

Tips & Best Practices

•Enable OCSP stapling to improve TLS handshake performance
•Monitor OCSP response freshness to avoid serving stale data
•Configure OCSP stapling timeout for reliable operation
•Test OCSP stapling from multiple clients for compatibility

Technical Details

Protocol: Online Certificate Status Protocol (OCSP) stapling support
Performance: Handshake improvement through cached OCSP responses
Freshness: OCSP response freshness and update mechanism
Output: OCSP stapling status with configuration recommendations