[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.
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.
It also means that the client software no longer needs to disclose users' browsing habits to any third party.
When OCSP stapling is used, the certificate status information is delivered to the client through an already established channel, reducing overhead and improving performance.
[9] TLS developer Adam Langley discussed the extension in an April 2014 article following the repair of the Heartbleed OpenSSL bug.
The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.
[23] For SMTP the Exim message transfer agent supports OCSP stapling in both client [24] and server [25] modes.