How is OCSP Stapling used in practice?

See real-world examples and code snippets on the OCSP Stapling glossary page at CDN Certified.

OCSP Stapling

Q: Is Certificate Status Request the same as OCSP Stapling?

Yes. OCSP Stapling is also known as Certificate Status Request, status_request. OCSP stapling has the TLS server fetch a CA-signed proof that its certificate is not revoked and attach it to the handshake, so the client never contacts the CA: no extra connection, no privacy leak. It only works if the issuing CA still publishes OCSP.

Security

OCSP stapling has the TLS server fetch a CA-signed proof that its certificate is not revoked and attach it to the handshake, so the client never contacts the CA: no extra connection, no privacy leak. It only works if the issuing CA still publishes OCSP.

Also known as Certificate Status Request, status_request.

10 min read Updated Aug 30, 2026

Full Explanation

OCSP stapling makes the TLS server fetch a signed proof that its certificate has not been revoked. On a CDN, that server is the edge server. The server attaches that proof to the TLS handshake. This way, the client never has to ask the certificate authority itself. The proof is an Online Certificate Status Protocol (OCSP) response. The stapling part is the TLS extension that carries it in band. Formally, it is the Certificate Status Request extension (status_request). Stapling is not revocation. It is also not a way around the CA. The response is still signed by the CA, or by a responder the CA authorises. The server only caches it and re-serves it to everyone. One fact frames the rest: the CA/Browser Forum no longer requires a public CA to run OCSP at all. So several large CAs have stopped publishing it. A certificate with no OCSP URL has nothing to staple.

How it works

OCSP exists so a client can learn one certificate's revocation state. It does this without pulling a whole Certificate Revocation List (CRL). RFC 6960 section 2 opens on exactly that trade-off: "In lieu of, or as a supplement to, checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of certificates". A responder replies with a signed message. That message carries one of three statuses: good, revoked or unknown RFC 6960 section 2.2. Note how weak "good" is. It means no certificate with that serial number is currently recorded as revoked. It "does not necessarily mean that the certificate was ever issued".

Fetching that answer itself costs the client a whole extra connection. That connection needs DNS, then TCP, then HTTP, before any content can flow. So it adds at least one round trip to the handshake. Fastly, writing in 2015, called it "an extra round-trip connection from the client to the CA's OCSP endpoint before the TLS session can proceed to delivering content from the server to the client". Fastly also cited observers placing the median time to connect to an OCSP server at about 300 ms, with a mean of up to a second Fastly, Addressing TLS Revocation and OCSP Challenges.

Stapling moves that work off the client and onto the server:

The client asks for status by sending the status_request extension in its ClientHello RFC 6066 section 8.
A server holding a response fetched out of band returns it. This is a MAY, not a MUST. A server may send nothing, and clients must cope.
In TLS 1.2 the server sends it in a CertificateStatus message. This comes immediately after the Certificate message. RFC 6066 is blunt about the limit: "Only one OCSP response may be sent." The staple therefore speaks for the leaf certificate alone RFC 6066 section 8.
In TLS 1.3 it rides as an extension inside the CertificateEntry holding the certificate it describes. This allows a status per certificate in the chain. The older multi-status extension status_request_v2 (RFC 6961) is deprecated. TLS 1.3 servers must not act on it RFC 8446 section 4.4.2.1.
A client that asked for status and got one MUST check it. If the response is not satisfactory, the client must abort with the always-fatal bad_certificate_status_response alert RFC 6066 section 8.

Reuse is what makes this cheap. Each response carries a validity window, thisUpdate to nextUpdate RFC 6960 section 2.4. The current Baseline Requirements state that "OCSP responses for Subscriber Certificates MUST have a validity interval greater than or equal to eight hours and less than or equal to ten days" CA/Browser Forum TLS Baseline Requirements. One fetch from the CA therefore covers every handshake until the response nears expiry. The direction can reverse too. A TLS 1.3 server may ask a client to staple status for its client certificate. This matters wherever mTLS is in play RFC 8446 section 4.4.2.1.

Why it matters for a CDN

A CDN terminates TLS for many hostnames on many machines. This changes the arithmetic three times over.

Amortisation. One cached response serves every connection an edge server handles. The busier the property, the better the trade: "The performance improvement of OCSP stapling is more pronounced when CloudFront receives numerous HTTPS requests for objects in the same domain" AWS CloudFront developer guide.
Fan-out is the catch. The cache is per server, not per region: "Each server in a CloudFront edge location must submit a separate validation request". On a quiet distribution, "the viewer separately performs the validation step" because the server it reached has not fetched yet AWS CloudFront developer guide. Thousands of edge servers multiply that first-connection miss.
Privacy. A live client check tells the CA which site is being visited. It tells every on-path observer too. In band, "the privacy, performance, and reliability concerns arising from the need to make a third-party connection during the TLS handshake are eliminated" RFC 7633 section 3.

Be honest about who still benefits. Chromium's security FAQ says Chrome clients "do not, by default, perform" online revocation status checks "using CRLs directly or via OCSP URLs included in certificates". By default, though, "stapled Online Certificate Status Protocol (OCSP) responses are honored" Chromium security FAQ. Mozilla enabled CRLite for all Firefox desktop users in Firefox 137. Mozilla also said it would disable OCSP for domain-validated certificates in Firefox 142 Mozilla, CRLite in Firefox. Stapling therefore buys less handshake latency than it did in 2015. It still hands Chrome revocation evidence it would otherwise never fetch.

What CDNs do

Pre-fetch centrally, then distribute. Cloudflare's first design fetched opportunistically. That guaranteed no staple on the first request in every region, and after every expiry. Its 2017 redesign inverted that: "Instead of fetching the OCSP response when a request came in, we would fetch it in a centralized location and distribute valid responses to all our servers." It then reported responses on "over 99.9% of connections". It stated the standing condition plainly: "As long as the certificate authority has set up OCSP for a certificate, Cloudflare will serve a valid OCSP stapled response." Cloudflare, High-reliability OCSP stapling.
Or fetch lazily, per server. CloudFront validates the certificate and caches the CA's response at the edge, "so the client doesn't need to validate the certificate directly with the CA". A server that has not fetched yet lets the viewer check the certificate while it fetches for next time AWS CloudFront developer guide. This is simpler, at the price of the cold-server gap.
Nothing to staple once the CA leaves. Let's Encrypt turned its OCSP service off on 6 August 2025. It had already "stopped including OCSP URLs in our certificates more than 90 days" earlier, and now publishes revocation information only via CRLs Let's Encrypt, OCSP Service Has Reached End of Life. Google Trust Services said it would "discontinue embedding OCSP information for the majority of our certificate chains" Google Trust Services, OCSP Support Changes. It later moved removal to 1 May 2026 Google Trust Services, OCSP Support Update. On certificates from those CAs there is no stapling to switch on.

Watch out for

Soft fail means a missing staple proves nothing. Where clients check at all, most behave as Cloudflare describes: "If the revocation information is available, they rely on it, and otherwise they assume the certificate is not revoked and display the page without any errors" Cloudflare, High-reliability OCSP stapling. RFC 7633 makes the same point: "a client cannot draw any conclusion from the absence of in-band status information" RFC 7633 section 3.
Must-staple closes that hole, and is now a dead end for many. A TLS feature extension in the end-entity certificate "permits a client to fail immediately if the certificate status information is not provided by the server" RFC 7633 section 3. This comes at the price of giving the CA a veto over your availability. Supply has also dried up. From 7 May 2025, Let's Encrypt failed "all requests including the OCSP Must Staple extension" Let's Encrypt, Ending OCSP Support in 2025.
Turning stapling on for a certificate with no OCSP URL is a silent no-op. The Baseline Requirements' OCSP rules bind only certificates "which include an Authority Information Access extension with an id-ad-ocsp accessMethod". A CA need only operate "its CRL and optional OCSP capability" CA/Browser Forum TLS Baseline Requirements. Check the certificate, not the config file.
A stale staple is worse than none. Before accepting a response, a client must confirm that thisUpdate "is sufficiently recent" and that nextUpdate "is greater than the current time" RFC 6960 section 3.2. Serve an expired one, and a strict client takes the fatal-alert path instead of connecting.
In TLS 1.2 the chain stays unproven. The single permitted response covers the leaf. Intermediate revocation is therefore invisible on that handshake. Only TLS 1.3 carries status per certificate.
Stapling survives split key custody. An OCSP response is signed on the CA side and is public. Serving one therefore needs none of the server's private key material: an edge running keyless SSL can still staple.

Best practice

Check first whether your CA publishes OCSP. Look for an OCSP URI in the certificate's Authority Information Access extension. If there is none, there is nothing to configure. Revocation then reaches clients by CRL-derived mechanisms instead.
On servers you run yourself, enable it deliberately: nginx defaults ssl_stapling to off. It also needs the issuer certificate, in the chain or via ssl_trusted_certificate. In nginx's words, "For a resolution of the OCSP responder hostname, the resolver directive should also be specified." nginx ngx_http_ssl_module.
At fleet scale, fetch once and ship the bytes instead of letting every machine query the CA. ssl_stapling_file takes the response "from the specified file instead of querying the OCSP responder specified in the server certificate" nginx ngx_http_ssl_module. This is the same shape as Cloudflare's centralised pre-fetch.
Verify from an outside network with openssl s_client -connect host:443 -status -servername host. Look for "OCSP Response Status: successful" and "Cert Status: good". A missing staple shows up as "OCSP responses: no responses sent".
Monitor freshness against nextUpdate and refresh with hours to spare. That way, a failed fetch has room to retry before the staple you are serving goes stale.
Treat must-staple as a specialist tool, not a default. Never read a missing staple as a healthy certificate. Investigate it, because most clients will not complain for you.

Examples

Enable OCSP stapling in Nginx:

server {
    listen 443 ssl;

    ssl_certificate     /etc/ssl/cdn.example.com.crt;
    ssl_certificate_key /etc/ssl/cdn.example.com.key;

    # Enable OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/chain.pem;

    # DNS resolver for OCSP responder lookups
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

Check the stapling status:

# Check if stapling is active
openssl s_client -connect cdn.example.com:443 \
    -status -servername cdn.example.com 2>/dev/null \
    | grep -A 5 "OCSP Response"

# Expected output:
# OCSP Response Status: successful (0x0)
# OCSP Response Data:
#     Response Status: good
#     This Update: Mar 01 00:00:00 2026 GMT

Frequently Asked Questions

Enable OCSP stapling in Nginx:

server {
    listen 443 ssl;

    ssl_certificate     /etc/ssl/cdn.example.com.crt;
    ssl_certificate_key /etc/ssl/cdn.example.com.key;

    # Enable OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/chain.pem;

    # DNS resolver for OCSP responder lookups
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;
}

Check the stapling status:

# Check if stapling is active
openssl s_client -connect cdn.example.com:443 \
    -status -servername cdn.example.com 2>/dev/null \
    | grep -A 5 "OCSP Response"

# Expected output:
# OCSP Response Status: successful (0x0)
# OCSP Response Data:
#     Response Status: good
#     This Update: Mar 01 00:00:00 2026 GMT

Yes. OCSP Stapling is also known as Certificate Status Request, status_request. OCSP stapling has the TLS server fetch a CA-signed proof that its certificate is not revoked and attach it to the handshake, so the client never contacts the CA: no extra connection, no privacy leak. It only works if the issuing CA still publishes OCSP.

Previous Term Negative Caching

Next Term Origin

Back to Glossary