OCSP Stapling is known as TLS certificate status Request extension used to check the status of certificate revocation of x.509 digital certificate. OCSP is useful for clients who possess limited processing power and memory and even for CAs who have large CRLs (Certificate Revocation Lists). OCSP can provide more appropriate information about the revocation of a certificate than CRL. OCSP can check the certificate issued by CA while CRL only provides the revocation list of serial numbers and therefore, it is possible to detect the usage of fraudulent certificate.
OCSP request made by browser itself takes much time in SSL handshake and creates traffic burden on the CA. To handle large sites that serving multiple users, the CA must build a significant infrastructure to handle all those requests. To overcome this issue, Internet Engineering Task Force’s TLS Working Group defined an extension to the TLS protocol referred to as OCSP stapling. It uses TLS server as a proxy and provides OCSP response for site’s certificate and passes on to clients that asking for the response for TLS handshake. As the response comes directly from the server, there is no need to obtain request information from issuer that can augment site performance.
By mitigating privacy concern and burden of the infrastructure demands, it makes faster web page loading. OCSP stapling is at present backed by IIS 7+, Apache 2.4+ (must be manually enabled) and Nginx 1.7.3+. Some facts about OCSP stapling are defined as under.
- In the latest Netcraft survey, 22% of certificates were processed with OCSP stapling.
- All these 22% of certificates were using Microsoft window.
- 94.54% Window server 2008 use OCSP stapling.
- 1.76% Window server 2012 uses OCSP stapling.
- Linux and other unknown operating system contribute 1.39 & 1.25% respectively in OCSP stapling usage.
Below table shows browser wise support of OCSP stapling.
Browser/OS | Windows | Linux | Mac OS X | IOS | Android |
Chrome 28 |
Yes |
Yes |
No |
No |
No |
Firefox 22 |
No |
No |
No |
N/A |
No |
IE 10 |
Yes |
N/A |
N/A |
N/A |
N/A |
Safari 6 |
No |
N/A |
No |
No |
N/A |
Opera 12 |
Yes |
Yes |
Yes |
N/A |
N/A |
Opera 15 |
Yes |
N/A |
No |
N/A |
N/A |
Opera Mini |
N/A |
N/A |
N/A |
Yes |
Yes |
Opera Mobile |
N/A |
N/A |
N/A |
N/A |
No |
The main drawback of OCSP stapling is it increases the traffic size per full handshake; however, such size is negligible compare to encrypted data sent over the connection. OCSP stapling only runs for site certificates and never checks the validity of intermediate CA certificates in the certificate chain and clients have to check individually certificate’s validity with CRLs or OCSP responses.
To avoid this limitation, OCSP multiple stapling has come into force that carries OCSP requirement in intermediate CA certificate. Now it is possible to use OCSP stapling for intermediate certificate. Checking intermediate certificate information with OCSP stapling is referred to multi stapling. Some reviewers also raised a question that size of multiple stapling will increase the handshake delay. To mitigate this hurdle, Certificate Authority has to keep their OCSP response small (512 bytes) and try to avoid assigned OCSP signing certificate.
It is necessary to check cancelled certificate as it will be unsafe for website users and organization and hackers can compromise the revoked certificate and may steal user’s data. OCSP stapling is one-step ahead than CRL, as it understands better the situation of revocation certificate.