ReferenceSSL & TLS·8 min read

What Is OCSP Stapling? How Does Certificate Revocation Work?

A certificate can be revoked before it expires — but without active checking, browsers may still trust it. OCSP stapling is the mechanism that makes revocation checks fast, private, and reliable. Here's how it works and what breaks when it doesn't.

Key takeaways

  • A certificate's expiry date is not the only validity condition — it can be revoked by the CA at any time.
  • Without OCSP stapling, browsers must contact the CA directly on every TLS handshake — adding latency and leaking browsing behaviour.
  • OCSP stapling moves the revocation check to the server, which caches and delivers the CA response to clients during the handshake.
  • Misconfigured OCSP stapling can silently degrade TLS connections or, with Must-Staple, cause complete connection failure.

In this article

Why certificates can be revoked

An SSL/TLS certificate is issued with a validity window — a notBefore andnotAfter date. Within that window, the certificate is presumed valid. But circumstances can make a certificate unsafe before it expires:

  • Private key compromise — the server's private key is leaked or stolen. Any traffic encrypted with the corresponding certificate can potentially be decrypted.
  • Certificate misissue — the CA issued the certificate for the wrong domain, to the wrong organisation, or in violation of the Baseline Requirements.
  • Subscriber request — the domain owner no longer controls the domain or wants the certificate removed from use.
  • CA infrastructure issue — the CA itself discovers a systemic problem with how a batch of certificates was issued.

In any of these cases, the CA adds the certificate's serial number to its revocation records. The challenge: how do clients know a certificate has been revoked before they connect?

CRLs — the original revocation mechanism

The original mechanism was the Certificate Revocation List (CRL) — a signed list of revoked serial numbers that CAs publish periodically.

Challenges with CRLs:

  • CRLs can be megabytes in size for large CAs — expensive to download and parse on every request.
  • They're updated periodically (hourly, daily), not in real time — there's always a freshness window.
  • Browsers often skip CRL checks in practice because downloading them adds too much latency.

CRLs are still used for code signing certificates and some enterprise PKI setups, but are impractical at scale for web TLS.

OCSP — Online Certificate Status Protocol

OCSP (RFC 6960) replaced CRLs with a lighter-weight query mechanism. Instead of downloading a full list, a client sends a single request containing one certificate serial number to the CA's OCSP responder URL (embedded in the certificate itself under Authority Information Access). The responder replies with one of three statuses:

good

Certificate is currently valid and not revoked.

revoked

Certificate has been revoked. The connection should be rejected.

unknown

The responder has no information about this certificate.

OCSP is more practical than CRLs — but it still has problems:

  • Privacy — every time a user visits an HTTPS site, their browser sends the certificate serial number to the CA's OCSP server. The CA can log which users are visiting which sites.
  • Latency — adds a round trip to every TLS handshake, typically 50–300 ms depending on the CA's responder location and the user's network.
  • Soft-fail behaviour — if the OCSP responder is unreachable (maintenance, DDOS, network issue), most browsers proceed with the connection anyway. This means a targeted DDOS of a CA's OCSP responder could effectively disable revocation checking for all certificates it issued.

OCSP stapling — how it improves on both

OCSP stapling (RFC 6961) shifts the OCSP query from the client to the server. Here's how it works:

1

Server fetches its own OCSP response

The web server periodically queries the CA's OCSP responder for its own certificate's status — typically every 24–48 hours.

2

CA returns a signed, timestamped response

The CA's responder returns a signed OCSP response with a validity window (the nextUpdate field indicates when it expires).

3

Server caches the response

The server stores this signed response in memory or on disk.

4

Stapled to the TLS handshake

When a client connects, the server includes the signed OCSP response alongside its certificate in the TLS handshake — 'stapling' it to the exchange.

5

Client verifies without contacting CA

The client receives the signed OCSP response directly from the server. No separate request to the CA — faster handshakes, no privacy leak. The CA's signature proves authenticity.

The key insight: the OCSP response is signed by the CA, so clients can verify its authenticity. A malicious server cannot fake a "good" response — and can't omit the response (in standard OCSP stapling) without triggering the client to fall back to direct OCSP, which still reveals the true status.

OCSP Must-Staple

Standard OCSP stapling is optional. If the server doesn't provide a stapled response, clients fall back to direct OCSP queries — re-introducing the latency and privacy concerns of plain OCSP.

The TLS Feature extension (RFC 7633), commonly called "Must-Staple", embeds a requirement directly in the certificate: the servermust provide a valid stapled OCSP response, or the connection must be rejected.

Must-Staple eliminates the soft-fail loophole — but it requires the server to reliably fetch and serve fresh OCSP responses. If the server fails to renew its cached response before it expires, every connection to the server fails until the response is refreshed. It's a security improvement with an operational cost.

What goes wrong

Common OCSP failure modes

  • ›Stapling not enabled: Clients fall back to direct OCSP — slower, CA-visible, and soft-fail if the responder is slow. Silent degradation with no visible error.
  • ›Stale stapled response: Server can't reach the CA to refresh its OCSP response, the cached response expires, and the staple becomes invalid — clients reject or fall back.
  • ›Must-Staple with stale response: If the certificate includes the Must-Staple extension but the stapled response has expired, every client connection to the server fails with a TLS error. Hard failure, zero visibility without monitoring.
  • ›Revoked certificate without monitoring: A revoked certificate without OCSP stapling is effectively trusted by browsers that use soft-fail OCSP. The certificate appears valid in monitoring tools that only check expiry.

What Aideworks monitors

Aideworks actively checks OCSP status as part of its SSL monitoring — going beyond expiry dates:

  • Revocation status — queries the CA's OCSP responder directly to confirm the certificate isn't revoked, regardless of whether stapling is in use.
  • Stapling presence — verifies that the TLS handshake includes a valid stapled OCSP response.
  • Stapled response freshness — checks the nextUpdate field to ensure the stapled response isn't expired or about to expire.
  • Must-Staple compliance — if the certificate includes the TLS Feature extension, Aideworks verifies a valid staple is always present.

For more on the broader SSL monitoring picture, read Beyond Expiry Dates: SSL Security Checks Your Agency Is Missing.

Monitor OCSP and full SSL health with Aideworks

Aideworks checks revocation status, OCSP stapling freshness, and certificate chain validity on every monitored domain — not just the expiry date.

Start monitoring free →