|This article needs additional citations for verification. (February 2012)|
OCSP stapling, formally known as the TLS Certificate Status Request extension, is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses, instead of the issuing certificate authority (CA).
OCSP has several advantages over older Certificate Revocation List (CRL)-based certificate revocation-checking approaches. However, OCSP can introduce a significant penalty for certificate authorities because it requires them to provide responses to every client of a given certificate in real time. When the certificate is issued to a legitimate high traffic web site, for instance, this can result in enormous volumes of OCSP request traffic, all of which serves to indicate that the certificate is valid and can be trusted.
OCSP checking also impairs privacy, since it requires the client to contact a third party (the CA) to confirm certificate validity. A way to verify validity without disclosing browsing behavior would be desirable for some groups of users.
OCSP stapling resolves both problems in a fashion reminiscent of the Kerberos Ticket. In a stapling scenario, the certificate holder queries the OCSP server themselves at regular intervals, obtaining a signed time-stamped OCSP response. When the site's visitors attempt to connect to the site, this response is included ("stapled") with the TLS/SSL Handshake via the Certificate Status Request extension response (note: the TLS client must explicitly include a Certificate Status Request extension in its ClientHello TLS/SSL handshake message). It may appear that allowing the site operator to control verification responses would allow a fraudulent site to issue a false verification for a revoked certificate, however, the stapled response is signed by the certificate authority, not the certificate holder (site operator), so stapled responses can't be forged (without the CA's signing key). Also, an invalid stapled response (or no stapled response) will just cause the client to ask the OCSP server directly. The only increased risk with this approach is a time delay in propagating the notification of revocation for a period of time up to the length of the query interval.
As a result, clients continue to have verifiable assurance from the certificate authority that the certificate is presently valid (or was quite recently), but no longer need to individually contact the OCSP server. This means that the brunt of the resource burden is now placed back on the certificate holder. It also means that the client software no longer needs to disclose users' browsing habits to any third party.
Overall performance is also improved: When the client fetches the OCSP response directly from the CA, it usually involves the lookup of the domain name of the CA's OCSP server in the DNS as well as establishing a connection to the OCSP server. When OCSP stapling is used, the certificate status information is delivered to the client through the established channel, which improves performance.
The TLS Certificate Status Request extension (colloquially known as OCSP stapling) is specified in RFC 6066, Section 8.
RFC 6961 defines Multiple Certificate Status Request extension, which allows a server to send multiple OCSP responses in the TLS handshake.
A draft proposal for an X509v3 extension field specifying that a compliant server presenting a certificate carrying the extension MUST return a valid OCSP token in its response if the status_request extension is specified in the TLS client hello expired in April 2013. Current version of the proposal has been extended to support also other TLS extensions. TLS developer Adam Langley discussed the extension in an April 2014 article following the repair of the Heartbleed OpenSSL bug.
Apache HTTP Server supports OCSP stapling since version 2.3.3, the nginx web server since version 1.3.7, LiteSpeed Web Server since version 4.2.4, Microsoft's IIS since Windows Server 2008, HAProxy since version 1.5.0, and F5 Networks BIG-IP since version 11.6.0.
OCSP stapling is designed to reduce the cost of an OCSP validation---both for the client and the OCSP responder---especially for large sites serving many simultaneous users. However, OCSP stapling supports only one OCSP response at a time, which is insufficient for certificate chains with intermediate CA certs.
- P. Hallam-Baker, X.509v3 Extension: OCSP Stapling Required
- P. Hallam-Baker X.509v3 TLS Feature Extension draft-hallambaker-tlsfeature-05
- A. Langley, No, don't enable revocation checking, April 19, 2014.
- Apache HTTP Server mod_ssl documentation - SSLUseStapling directive
- nginx-announce mailing list - nginx-1.3.7
- Release Log - Litespeed Tech. Retrieved 2014-02-07,
- Duncan, Robert. "Microsoft Achieves World Domination (in OCSP Stapling)". Netcraft Ltd. Retrieved 28 April 2014.
- HAProxy website
- Release Note: BIG-IP LTM and TMOS 11.6.0
- OCSP Stapling in Firefox, retrieved 2013-07-30
- Improving Revocation - MozillaWiki, retrieved 2014-04-28
- "How Certificate Revocation Works". TechNet. Microsoft. 16 March 2012. Retrieved 28 April 2014.
- "Issue 361820: Check For Server Certificate Revocation checkbox is confusing". Google Code. Google. 10 April 2014.
- The smtp transport, retrieved 2015-01-24
- Main configuration, retrieved 2015-01-24
- Mozilla NSS Bug 360420, Comment by Adam Langley
- Mozilla NSS Bug 611836 - Implement multiple OCSP stapling extension
- Pettersen, Yngve N. (June 2013). "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension". Internet Engineering Task Force. Retrieved 31 October 2014.