| created on | August 26, 2026 |
Instead of downloading –a potentially large– CRL, the client sends the certificate’s serial number to an OCSP responder. The OCSP responder replies with one of the status of good, revoked, or unknown. If it cannot process the request, it may return an error code. The details are outlined in RFC 6960 .
OCSP was first standardized in 1999 in RFC 2560, and CAs set up OCSP responders. But browsers didn’t implement OCSP until Internet Explorer enabled it by default in 2006. Firefox and Apple followed in 2008 and in 2011. The CAs setting up the infrastructure for OCSP had no traffic on it for years and thus didn’t spend too much resource on it. Thus, when traffic on OCSP-responders eventually started, failures were pretty common, which led browser to adopt the soft fail practice – if the OCSP-responder didn’t respond, browsers assumed everything to be ok, and just proceeded, assuming the certificate in question was valid. So, OCSP provided a golden opportunity for attackers.
An attacker who wants to abuse a compromised server’s private key typically does this with a man-in-the-middle attack, and starts impersonating that server. Being in the man-in-the-middle position, an attacker can also interfere with a client’s OCSP queries, either by blocking them – which is enough if the client uses the soft fail practice described above, or by replay attacks, where the attacker intercepts a good response and replays this response after a certificate has been revoked.
In RFC 8954 , a nonce extension was introduced. But because of high traffic load, most OCSP responders didn’t use a nonce to secure the response against replay attacks, but used pre-signed responses with a validity of several days – the next ill-conceived practice that was praying for trouble.
Does an OCSP-responder report all certificates issued by a compromised CA as revoked? Well, it MAY do so. Section 2.7 of RFC 6960, CA Compromise states: “If an OCSP responder knows that a particular CA’s private key has been compromised, it MAY return the “revoked” state for all certificates issued by that CA.”.
This is because although OCSP seems to happen in real time, it isn’t. Responses are cached and used for up to ten days. Section 2.4 and Section 2.5 of RFC 6960 describe the semantics and methods of response pre-production, but do not state any maximum time-span for response validity. However, Let’s Encrypt’s Certificate Policy states a valid time-span from 4 to 10 days prior to 2020-09-30 and a valid time-span for validity of 8 hours to 10 days after 2020-09-30 (see Internet Security Research Group (ISRG), Certificate Policy, Version 3.0, Updated July 19, 20214.9.10 On-line revocation checking requirements ).
For high traffic websites, OCSP-responders have to handle massive volumes of OCSP requests. On the other hand, an OCSP-responder can track what servers a client is accessing, leading to privacy concerns. Even when a CA is highly trusted and not willing to record the clients’ requests, it might be forced to do so by government agencies.
OCSP-stapling can mitigate both problems. In OCSP-stapling, the server retrieves its certificate status from an OCSP-responder and receives a signed time-stamped OCSP response. If a TLS client includes a Certificate Status Request extension in its ClientHello TLS/SSL handshake message, the server attaches (staples) the OCSP response to its certificate. The client does no longer have to connect to an OCSP-responder and can check the revocation status from the OCSP response stapled to the server’s certificate.
Originally, OCSP-stapling only supported stapling of one OCSP response, which is insufficient to validate certificate chains with intermediate CA certificates. This has been addressed in RFC 6961, The Transport Layer Security (TLS) Multiple Certificate Status Request Extension, which allows for multiple OCSP responses stapled to a certificate. TLS 1.2 allows only one OCSP response being stapled to certificates sent by a server. TLS 1.3 removes this limitation, allowing multiples OCSP responses being stapled to a certificate, which allows for a certificate chain with intermediate CAs to be verified.
RFC 9325 depicts the situation with OCSP:
" [...] However, using this facility remains impractical because many certification authorities (CAs) either do not publish OCSP for CA certificates or publish OCSP reports with a lifetime that is too long to be useful. "
Y. Sheffer, P. Saint-Andre, T. Fossati, RFC 9325
In July 2023, the CA/Browser Forums’s Ballot SC063v4 made OCSP optional, made CRLs are requirement, and paved the road for automatized certificate distribution with short-lived certificates.
For small environments, where servers are under one administrative control and less traffic for certificate validation is expected, OCSP might seem ok. But it can be expected that browsers phase out OCSP support altogether.
In July 2024, Let’s Encrypt announced that it is phasing out its OCSP service, citing privacy concerns and the substantially higher burden of maintenance compared to CRLs, reminding the public of its support for CRL, which it introduced in 2022.
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP RFC 6960
Online Certificate Status Protocol (OCSP) Nonce Extension RFC 8954
Internet Security Research Group (ISRG) Certificate Policy, Version 3.0, Updated July 19, 20214.9.10
Internet Security Research Group (ISRG), Certificate Policy, Version 3.0, Updated July 19, 20214.9.10
On-line revocation checking requirements
The Transport Layer Security (TLS) Multiple Certificate Status Request Extension RFC 6961
IETF RFC 9325 , see section 7.5. Certificate Revocation
CA/Browser Forum Ballot SC063v4: Make OCSP Optional, Require CRLs, and Incentivize Automation
Josh Ass, Let' Encrypt Blog, July 23, 2024 Intent to End OCSP Service