Introduction to OCSP Stapling

Introduction

SSL/TLS certificates act as digital IDs that let a browser confirm a website’s identity before any data is exchanged. Part of that trust depends on revocation: a mechanism that tells a browser when a certificate is no longer safe to use, whether because a server was compromised, a key was mistakenly exposed, or a Certificate Authority (CA) simply issued the certificate in error. OCSP Stapling was built to deliver that revocation status quickly and privately, but the CA landscape supporting it has shifted substantially since this mechanism became a best practice, and this guide covers exactly what changed.

The 50-Word Version

OCSP Stapling lets a web server fetch a signed certificate status response from its Certificate Authority in advance and attach it directly to the TLS handshake, so a visiting browser gets revocation status without contacting the CA itself. It improves speed and privacy over standard OCSP, but only works if the issuing CA still operates an OCSP responder.

At a Glance

• OCSP Stapling removes the need for a browser to contact the CA directly, improving both connection speed and visitor privacy compared to standard OCSP.
• Let’s Encrypt, the CA behind roughly half the web’s TLS certificates, disabled issuance of OCSP Must-Staple certificates on January 30, 2025, and shut down its OCSP responders entirely on August 6, 2025.
• That means OCSP Stapling has nothing to staple for any current Let’s Encrypt certificate; servers relying on it for those certificates need to move to Certificate Revocation Lists (CRLs) instead.
• Google Chrome, the most widely used browser, has never natively enforced the OCSP Must-Staple hard-fail behavior, relying instead on its own CRLSet mechanism, which limits how much protection Must-Staple actually adds even where a CA still supports it.
• Whether OCSP Stapling still makes sense for a given certificate now depends entirely on whether its issuing CA still runs an OCSP responder, which needs to be verified per CA rather than assumed.

Why This Needs an Update

Let’s Encrypt announced in December 2024 that it would phase out OCSP entirely during 2025, and it followed through on a strict timeline. On January 30, 2025, it disabled issuance of new certificates carrying the OCSP Must-Staple extension. By May 7, 2025, it removed OCSP URLs from newly issued certificates altogether. On August 6, 2025, it shut its OCSP responders down completely, moving fully to Certificate Revocation Lists. For any server presenting a Let’s Encrypt certificate issued after that point, OCSP Stapling is not a slower or less private option, it is simply unavailable, since there is no responder left to staple a response from.

DigiCert’s Trust Pulse Survey, published July 2, 2025, found that nearly half of enterprises experienced a certificate related outage in the past year, with 37.5% of incidents tied to expired certificates and 18.5% of affected organizations reporting losses exceeding $250,000. A server still configured to fetch and staple OCSP responses for a CA that no longer provides them is a quiet, easy-to-miss contributor to exactly this kind of outage risk, since a misconfigured or failing staple can degrade or break connections depending on client settings.

Certificate lifetimes are shrinking at the same time. Under CA/Browser Forum Ballot SC-081v3, approved April 11, 2025, publicly trusted TLS certificate validity drops from 398 days to 200 days starting March 15, 2026, then to 100 days from March 15, 2027, and to 47 days from March 15, 2029 onward. Shorter-lived certificates reduce the total window in which any revocation mechanism, staple or otherwise, actually matters, which is part of the broader industry reasoning behind moving away from OCSP altogether.

What Is OCSP Stapling?

Online Certificate Status Protocol (OCSP) Stapling is an internet standard used to verify the revocation status of an X.509 certificate without requiring the visiting client to contact the Certificate Authority directly. Instead, the web server itself periodically requests a signed status response from the CA’s OCSP responder and attaches, or staples, that response to the certificate during the TLS handshake. If the browser receives a revoked status, it warns the user and can block the connection before any confidential information is exchanged.

The OCSP Stapling Validation Flow

The table below walks through each step of the process along with what happens when something goes wrong.

Step	What Happens	Failure Mode	Monitoring Signal
1. Certificate issuance	The CA issues a certificate that includes an OCSP responder URL, signaling that OCSP is supported for this certificate	Certificate is issued with no OCSP URL, as Let’s Encrypt now does for all new certificates	Certificate inspection shows no Authority Information Access OCSP field
2. OCSP responder availability	The CA’s OCSP responder answers status queries and publishes updated status regularly	The CA has discontinued its OCSP responder entirely, as Let’s Encrypt did on August 6, 2025	Direct query to the responder URL times out or returns an error
3. Server fetches and caches a response	The web server requests a signed OCSP response and caches it for reuse across client connections	Server cannot reach the responder and has no cached response to staple	Server logs show repeated OCSP fetch failures
4. TLS handshake and stapling	The server attaches the cached OCSP response to the certificate during the handshake	Server presents a certificate with no staple, forcing clients back to standard OCSP or no revocation check at all	SSL Labs or equivalent scan reports OCSP Stapling as “No” or “Not supported”
5. Client verification	The browser checks the stapled response’s signature and status (good, revoked, or unknown)	Stale or expired staple leads some clients to fall back to a direct OCSP query or accept the connection anyway	Client-side TLS error logs or browser developer tools flag stapling issues

Certificate Response Types

Response	Meaning	Browser Behavior
Good	The OCSP responder recognizes the certificate’s serial number and confirms it has not been revoked	Connection proceeds normally
Revoked	The certificate has been explicitly revoked by the issuing CA	Hard stop; the browser blocks the connection and warns the user
Unknown	The responder does not recognize the certificate, often because it needs to be checked against a different CA than the one it is configured for	Soft stop; behavior varies by browser and may allow the connection to proceed

Advantages and Disadvantages of OCSP Stapling

Advantages

• Improved performance. The server caches and reuses the OCSP response, avoiding the extra round trip a client would otherwise make to the CA for every connection.
• Enhanced privacy. Because the CA answers the server’s periodic refresh request rather than a query for every individual visitor, it cannot see which specific users are visiting which sites.
• Resource efficiency. Stapling consumes fewer network resources than either standard OCSP queries per visitor or downloading a full Certificate Revocation List.

Disadvantages

• Total dependence on the issuing CA’s OCSP responder. If that responder is discontinued, as Let’s Encrypt’s now is, stapling simply has nothing to fetch, regardless of how well the server is configured.
• Limited chain coverage. Basic OCSP Stapling typically does not verify intermediate certificates in the chain, though multi-stapling and TLS 1.3 support address this in servers that implement them.
• Update latency. There is a real time gap between refresh cycles, so a certificate revoked moments after the last refresh may still show a stale “good” status until the next fetch.

Why Must-Staple Is Fading Too

The OCSP Must-Staple extension was designed to close a specific gap: without it, a server can simply omit the staple and a browser has no way to know one should have been present. Must-Staple hard-fails the connection if no valid staple is attached, in theory forcing servers to keep stapling correctly. In practice, its usefulness was always limited by uneven browser support, and it is now fading from the ecosystem entirely for a more direct reason. Google Chrome, the browser with the largest share of web traffic, has never natively enforced Must-Staple’s hard-fail behavior, instead relying on its own CRLSet mechanism to distribute revocation information at scale. On top of that, Let’s Encrypt disabled issuance of new Must-Staple certificates on January 30, 2025 as the first step in its broader OCSP shutdown. Between limited browser enforcement and the largest CA no longer issuing it, Must-Staple is not a control worth building new reliance on going forward.

Monitoring Checklist for OCSP Stapling Health

1. Confirm which CA issued each certificate in your environment and check whether that CA still operates an OCSP responder.
2. For certificates from a CA that has discontinued OCSP, disable stapling configuration for those certificates and confirm CRL checking is properly configured instead.
3. Run a revocation-checking scan against every public-facing hostname on a recurring schedule, not just at initial deployment.
4. Monitor server logs for repeated OCSP fetch failures, which indicate either a responder outage or a certificate from a CA that no longer supports OCSP.
5. Remove any remaining OCSP Must-Staple configuration on certificates from CAs that have deprecated the extension, since a hard-fail setting with nothing to staple can break connections outright.
6. Revisit this checklist whenever a CA in your environment announces an infrastructure change, not only on a fixed calendar schedule.

How to Check Whether OCSP Stapling Is Enabled

OCSP Stapling support today is a function of the web server software in use, such as a currently supported release of IIS, Nginx, Apache, or Caddy, rather than a specific legacy operating system version. Any modern, actively maintained server platform supports stapling; the practical question is whether it is configured correctly and whether the certificate’s issuing CA still has a responder to fetch from.

Step 1: Go to SSL Labs by Qualys.

Step 2: Check the box to avoid publishing the results on the public results board if the domain should stay private.

Step 3: Enter the domain name to check and submit the scan.

Step 4: Once the scan completes, review the Revocation Information section, which lists CRL and OCSP details.

Step 5: Check the OCSP Stapling row. A “Yes” means stapling is active. A “No” means it is disabled but the certificate still supports OCSP. A “Not supported” result may mean the issuing CA itself no longer provides OCSP at all, which is now the case for certificates from Let’s Encrypt, so confirm the issuing CA before assuming a server misconfiguration.

Who Should Care About This

The shift away from OCSP changes concrete configuration decisions across several roles.

PKI Administrators

Maintain server-level revocation configuration. Action item: audit every certificate for its issuing CA and remove OCSP Stapling or Must-Staple configuration for any CA that has discontinued OCSP support.

Security Architects

Set the organization’s revocation checking standard. Action item: define a CRL-based fallback policy for any certificate authority that no longer supports OCSP, rather than leaving it to each server team to discover independently.

Platform Teams

Own the actual server and load balancer configuration. Action item: run a revocation-checking scan across every public-facing hostname and fix any host still configured for OCSP Stapling against a CA that no longer supports it.

Compliance Teams

Confirm audit documentation reflects current CA behavior. Action item: update any compliance evidence that still cites OCSP Stapling as the default revocation mechanism if the relevant CA has moved to CRLs.

CISOs

Weigh the operational cost of maintaining per-CA revocation configuration against the risk of a silent misconfiguration. Action item: treat the Let’s Encrypt OCSP shutdown as a prompt to confirm revocation checking is current across the full certificate inventory, not only newly issued certificates.

Our Take: How Encryption Consulting Supports Certificate Revocation Management

OCSP Stapling was a meaningful improvement over standard OCSP for as long as CAs kept running responders behind it. With the largest CA on the web now fully off OCSP, the practical question for most organizations is no longer how to configure stapling correctly, it is which certificates still need it at all.

Our CertSecure Manager platform gives teams full machine identity inventory and certificate discovery, so a CA-level infrastructure change like this one surfaces as a known inventory update rather than a surprise outage. For organizations weighing whether to manage revocation infrastructure in-house at all, our PKI-as-a-Service platform runs the CA hierarchy, including revocation publishing, on FIPS 140-3 Level 3 HSM-backed keys while your organization retains ownership and control. For a closer look at how OCSP and CRLs compare more broadly, see our guide on OCSP vs. CRL, and for a related Windows-specific quirk, our post on the OCSP Magic Number covers a threshold that silently switches clients from OCSP to CRL checking. On the crypto-agility side, our PQC Center of Excellence and PQC Readiness Assessment help teams plan for a future where revocation infrastructure itself needs post-quantum-safe signing, and our CBOM Secure cryptographic discovery and inventory platform gives security architects visibility into exactly which certificates in an environment still depend on a deprecated OCSP configuration.

Conclusion

OCSP Stapling improved on standard OCSP by delivering revocation status faster and more privately, without requiring every visiting client to query the CA directly. That advantage, however, was always conditional on the issuing CA continuing to operate an OCSP responder, and the largest CA on the web no longer does. Let’s Encrypt’s phased shutdown, from disabling Must-Staple issuance in January 2025 to fully retiring its OCSP responders in August 2025, means the right move for many organizations is no longer tuning stapling configuration but confirming, certificate by certificate, whether OCSP is even still in play.

Frequently Asked Questions

What is the main takeaway from this introduction to OCSP Stapling?

OCSP Stapling improves the speed and privacy of certificate revocation checking, but it only works if the issuing CA still runs an OCSP responder. Let’s Encrypt, the largest CA on the web, fully retired its OCSP responders on August 6, 2025, making stapling unavailable for its current certificates.

Why does this matter for enterprise PKI teams?

Server configurations built around the assumption that OCSP Stapling is universally available may now be silently non-functional for certificates issued by CAs that have discontinued OCSP, creating an unmonitored gap in revocation checking.

What risks increase if this topic is handled manually?

Manually tracking which CA issued which certificate, and whether that CA still supports OCSP, does not scale, and a stale OCSP Must-Staple configuration can cause hard connection failures once a CA stops providing responses altogether.

Which teams should own this change?

PKI administrators own server-level revocation configuration, security architects set the CRL fallback standard, platform teams own scanning and remediation, compliance verifies documentation accuracy, and the CISO weighs the overall risk tradeoff.

How does this connect to certificate lifecycle management?

Certificate lifecycle management tooling that tracks which CA issued each certificate makes it possible to identify affected certificates quickly when a CA changes its revocation infrastructure, rather than discovering the gap through a connection failure.

How should organizations measure success?

Track the percentage of public-facing hosts with correctly configured revocation checking for their actual issuing CA, and confirm zero hosts are still configured for OCSP Stapling or Must-Staple against a CA that no longer supports it.

What should be audited or monitored regularly?

Regularly audit which CA issued each certificate, whether that CA still operates an OCSP responder, whether stapling is functioning where configured, and whether CRL fallback is correctly set up for certificates from CAs that have moved away from OCSP.

How does this topic affect cloud, hybrid, or multi-CA PKI?

An environment using certificates from multiple CAs may need different revocation configurations for each, since one CA discontinuing OCSP does not mean every CA in a multi-CA or hybrid environment has done the same.

What common mistakes should teams avoid?

Common mistakes include assuming OCSP Stapling works the same way across all CAs, leaving OCSP Must-Staple enabled on certificates from a CA that no longer issues OCSP responses, and treating a server’s OS version rather than the issuing CA’s current OCSP support as the deciding factor.

What should be refreshed quarterly?

Refresh the certificate inventory and its mapping to each issuing CA’s current OCSP support status, rerun revocation-checking scans against public-facing hosts, and check for newly announced CA infrastructure changes at least quarterly.