OCSP stapling decreases the load on a PKI infrastructure's OCSP server by attaching a signed OCSP response to the target in a TLS connection. In addition it creates a more secure/private session since the CA doesn't know that your browser is accessing a given site. Some people have compared this behavior to Kerberos.


  • What web browsers support OCSP stapling?

  • Are there any implementation considerations among different browsers that need to be addressed to maintain uniform privacy and performance benefits?

  • 1
    As a note - in a regular SSL session, the CA does not know the browser is accessing the site. There is nothing in the SSL protocol that involves the browser talking to the CA in anyway. Nor is OCSP required. I would not, in fact, call it "more secure" as some systems see having a fresh made-for-you OCSP response as the better security implementation. May 1, 2012 at 19:24
  • @bethlakshmi SSL has this revocation problem. CRLs get longer and longer. OCSP is a solution for that but it has the privacy (and soft fail) problem. Both can be solved with OCSP stabling (and must staple extension).
    – eckes
    Oct 17, 2014 at 19:22
  • @bethlakshmi I'm new to this, but doesn't SSL require browsers to ping the revocation lists from the CA? Sep 2, 2016 at 18:53
  • No, it does not. In the SSL/TLS handshake the server must provide a credential, and the type of acceptable credential can be specified by the client, but the credential is not required to be a PKI certificate, nor is the client required to verify the credential via CRL or OCSP. Most browsers implement a trusted cert store, check that the cert is not expired, and check that the cert includes the hostname of the targeted URL request. Most commercial browsers today don't check status unless a plug in or other addition is set. Sep 12, 2016 at 20:54

4 Answers 4


My impression is that OCSP stapling is not well supported on the client side, but it's possible my information might be out of date.

Firefox apparently supports OCSP stapling, as of Firefox 26. (Thanks to Jan Schejbal for this information.)

Chrome supports OCSP stapling on Windows, Linux, and ChromeOS. (Thanks to Kit Sunde for this information.) (The Chrome team has decided that they plan to remove CRL and regular OCSP checks, but they haven't disabled OCSP stapling.)

I've read one report that most browsers support OCSP stapling on Windows.

Here is some more information on browser support for OCSP (but not OCSP stapling, unfortunately).

  • Firefox 26 now includes OCSP stapling support as per an announcement on mozilla.dev.security.policy. Dec 13, 2013 at 4:56
  • Thanks, @JanSchejbal! I've updated the answer accordingly. I appreciate it.
    – D.W.
    Dec 13, 2013 at 5:01
  • Chrome hasn't disabled OCSP stapling. Only CRL and regular OCSP checks. code.google.com/p/chromium/issues/detail?id=361230#c8
    – Kit Sunde
    Jul 5, 2014 at 23:06
  • Thank you, @KitSunde, for the correction! I've updated the answer accordingly -- many thanks.
    – D.W.
    Jul 6, 2014 at 1:27
  • What do they mean by "but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed." in the Blog? Jul 6, 2014 at 1:49

You can test OCSP stapling support in Your browser on http://www.vpnhosting.cz/ocsp.

It is in Czech language, if You can see OCSP_stapling_disabled, OCSP stapling is disabled, OCSP_stapling_enabled means, that OCSP stapling works.

  • looks like Opera 12.01 on Linux does support it, nice Sep 25, 2012 at 11:34

IE has supported it since Vista, Chrome supports it on Windows via CryptoAPI and on other platforms via patches to NSS it made that Firefox has not accepted, Opera has also supported it for several years. Firefox has the worst revocation behavior of any browser on a number of fronts its lack of support of OCSP stapling being the smallest example. Also Chrome will continue to support OCSP and OCSP stapling in enterprise scenarios they have provided their own revocation checking mechanism for a variety of reasons.


Even with OCSP stapling, the act of verifying the OCSP signature may expose personal information to the OCSP signing root. Additionally the OCSP singing root can be a 3rd party to the entire infrastructure as shown here:

PKI hierarchy with two roots


Although there are security benefits to validating the signing OCSP signature, if privacy concerns outweigh security the following extension disables the signing functionality szOID_PKIX_OCSP_NOCHECK ( (note it is up to the CA to implement this extension)

If you want to use CRL instead of OCSP, you can set the following setting to 1 or zero on a Windows machine

  • Isn't this the case only when you want to check the validity of intermediate CA certificates in OCSP responder certificate and the OCSP stapled response doesn't have them already? In other words, it is a security hole but lot smaller than not checking revocation at all? Jul 12, 2012 at 11:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .