OCSP stapling

The original OCSP implementation has a number of issues.

Firstly, it can introduce a significant cost for the certificate authorities (CA) because it requires them to provide responses to every client of a given certificate in real time. For example, when a certificate is issued to a high traffic website, the servers of CAs are likely to be hit by enormous volumes of OCSP requests querying the validity of the certificate.[2]

Also, OCSP checking potentially impairs users' privacy and slows down browsing, since it requires the client to contact a third party (the CA) to confirm the validity of each certificate that it encounters.[2][3]

Moreover, if the client fails to connect to the CA for an OCSP response, then it is forced to decide between: (a) continuing the connection anyway; defeating the purpose of OCSP or (b) terminating the connection based on the assumption that there is an attack; but which could result in excessive false warnings and blocks.[4]

OCSP stapling is aimed at addressing these issues with the original OCSP implementation.[5][6]

OCSP stapling resolves both problems in a fashion reminiscent of the Kerberos ticket. In a stapling scenario, the certificate holder itself queries the OCSP server 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).[7]

While it may appear that allowing the site operator to control verification responses would allow a fraudulent site to issue false verification for a revoked certificate, the stapled responses can't be forged as they need to be directly signed by the certificate authority, not the server.[6] If the client does not receive a stapled response, it will just contact the OCSP server by itself.[4] However, if the client receives an invalid stapled response, it will abort the connection.[1] The only increased risk of OCSP stapling is that the notification of revocation for a certificate may be delayed until the last-signed OCSP response expires.

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.[2]

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 an already established channel, reducing overhead and improving performance.[5]

The TLS Certificate Status Request extension is specified in RFC 6066, Section 8.

RFC 6961 defines a 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, which expired in April 2013, specified 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.[8] The current version of the proposal has been extended to support additional TLS extensions.[9] TLS developer Adam Langley discussed the extension in an April 2014 article following the repair of the Heartbleed OpenSSL bug.[10]

OCSP stapling support is being progressively implemented. The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.

Apache HTTP Server supports OCSP stapling since version 2.3.3,[11] the nginx web server since version 1.3.7,[12] LiteSpeed Web Server since version 4.2.4,[13] Microsoft's IIS since Windows Server 2008,[14] HAProxy since version 1.5.0,[15] F5 Networks BIG-IP since version 11.6.0,[16] KEMP LoadMasters since Version 7.2.37.1, and lighttpd since version 1.4.56.[17]

While many web servers advertise support for OCSP stapling, implementations are not always reliable.[18] For example, when Apache queries the OCSP server, in the event of a temporary failure, it will discard the cached good response from the previous request, and start serving bad response.[19] Nginx performs lazy loading of OCSP responses, which means that for the first few web requests it is unable to add the OCSP response.[20]

On the browser side, OCSP stapling was implemented in Firefox 26,[4][21] in Internet Explorer since Windows Vista,[22] and Google Chrome in Linux, ChromeOS, and Windows since Vista.[23]

For SMTP the Exim message transfer agent supports OCSP stapling in both client [24] and server [25] modes.

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.[26][27]

This limitation has been addressed by Multiple Certificate Status Request Extension, specified in RFC 6961. It adds the support for sending multiple OCSP responses.[28]

TLSv1.3 automatically removes this limitation, making browser support for RFC 6961 moot, as more and more web servers drop support for TLS 1.2. Under TLS 1.2 only one stapled response can be sent by a server, the OCSP response associated with the end-certificate. Under TLS 1.3 a server can send multiple OCSP responses, typically one for each certificate in the certificate chain. [29]