Understanding Certificate Revocation Checks

Recently, there’s been some interest in how clients perform Certificate Revocation checks and browsers behave in the event that a revocation check cannot be completed. In today’s post, I’ll explain Internet Explorer’s default behavior and explain how you may change the default behavior if you want.

First, a bit of background: When a certificate authority issues a certificate to a secure website (e.g. https://www.fiddler2.com) that certificate typically contains information that allows the client browser to validate that the certificate was not issued in error (or compromised) and subsequently revoked by the certificate authority.

There are two mechanisms by which a client can validate that a certificate has not been revoked:

• Certificate Revocation Lists
  • In the CRL method, the browser downloads a file from the specified URL that contains every certificate which is not yet expired but has been revoked by the CA. This file may be several hundred kilobytes in size and is typically cached on the client computer for several days or more. The CRL file is itself signed by the CA to prevent tampering.
• Online Certificate Status Protocol
  • In the OCSP method, the browser contacts a web service running at the specified URL and asks the service whether a specific certificate has been revoked; again, the response is signed to prevent tampering. The response to the “Is certificate <XXX> revoked” query is typically much smaller than downloading an entire CRL file. If each OCSP request doesn't complete in less than 15 seconds, it times out.
  • A variant, called OCSP Stapling, allows the secure server to cryptographically prove that it has a recent “Yes this certificate is still valid” ticket that is signed by the CA. These tickets have a short lifetime and must be periodically renewed by the server in order to return a current ticket to clients in a TLS handshake. OSCP Stapling is the fastest and most private method of revocation checking, but it’s not yet deployed on most sites. OCSP Stapling is supported by IIS7 and later, and Mozilla is funding a project to add support to OpenSSL. OCSP Stapling is more private than regular OCSP because it does not result in your computer contacting the CA and telling it what secure site you've just visited.

TechNet has a great deep-dive explanation of how revocation checking is implemented in Windows.

Many certificates are configured to offer information for both revocation mechanisms; Windows XP’s HTTPS stack does not offer support for OCSP, and thus Internet Explorer only supports OCSP on Windows Vista and later.

Inside Tools > Internet Options > Advanced you will find the two options which control revocation checking. Check for server certificate revocation controls whether revocation checks occur for HTTPS connections. Check for publisher’s certificate revocation controls whether revocation checks occur when validating the Authenticode digital signatures on downloaded programs and ActiveX controls.

By default, Windows Vista and later enable revocation checks in both scenarios, while Internet Explorer on Windows XP only enables Authenticode Revocation checking by default because of the performance impact of downloading CRLs for HTTPS connections. If a CA indicates that a server’s HTTPS certificate was revoked, the user is blocked from navigating to a site; no override link is presented to allow the user to ignore the security warning. If a CA indicates that a downloaded binary’s signing certificate was revoked, the program will fail the Authenticode check and will not run.

However, if a given certificate specifies a CRL or OCSP URL, but the revocation check cannot be completed (say, because the Certificate Authority’s server is not reachable), Internet Explorer will not notify the user. In the original IE7 design, a notification (yellow address bar) was presented instead of the default lock icon. However, this design was reverted after testing when it was determined that connection problems to revocation servers were extremely common and there was no clear guidance the browser could give users about what they should do when a warning was encountered. Presenting unactionable and scary warnings to users in common and low-risk situations doesn’t improve security—it reduces it, by desensitizing users to higher value warnings where the degree of risk is far higher (e.g. SmartScreen malware warnings).

Having said that, we recognize that a certain subset of users would still prefer to see warnings when a certificate revocation check did not complete successfully. (One criticism of revocation checking is that most attacks against HTTPS sites require both control of a rogue certificate and control of the network/DNS, and if the attacker has control of the network/DNS, he may be able to block the client’s network request used to check for revocation.)

To that end, users may set an option (known as a Feature Control Key) to re-enable the warning UI. When a revocation check fails to complete, the lock icon will be replaced with an orange shield icon, like so:

The feature control key is named FEATURE_WARN_ON_SEC_CERT_REV_FAILED, and it is respected by IE7 and later. End-users may enable or disable the warning by running one of the following registry scripts and restarting their browser instances:

• Enable Revocation Check Warning for IExplore.exe
• Undo enabling revocation check warning for IExplore.exe

I still believe that the default configuration is the correct one for most users in most circumstances, but some technical users may wish to experiment with this option to understand the effectiveness of revocation servers in their environment and scenarios.

Web server owners should look into enabling OCSP Stapling to provide high-performance HTTPS connections for their visitors.

-Eric Lawrence

Update 8/16/2012:  We recently determined that URLMon's code (Win8, Win7, and probably earlier) to ignore certificate revocation check failures is not applied for content uploads (e.g. HTTP POST). Hence, if a Certificate Revocation check fails, that is fatal to the upload (e.g. IE will show a Page Cannot Be Displayed error message; other clients would show a different error). However, this rarely matters in the real world because in most cases, the user first performs a download (HTTP GET) from the target HTTPS site, and as a result the server's certificate is cached with the "ignore revocation check failures" exemption for the lifetime of the process and thus a subsequent POST inherits that flag and succeeds. The upload fails if the very first request to the HTTPS site in the current process was for an upload (e.g. as in a cross-origin POST request).

Comments

• Anonymous
  April 18, 2011
  What a shame, revocation checking is broken in MITM scenarios. Hopefully DNSSEC + this one extension will fix this. Oh, and why would Mozilla fund OSCP stapling support this in OpenSSL when they haven't even implemented it in NSS yet?

• Anonymous
  September 11, 2011
  Hi, Thanks for the great post - it cuts through the mountain of very detailed information on this subject very well. I have a question on this: If IE8 on XP has the default settings (Check for server certificate revocation = Off) then does that mean that IE8 on XP can never tell if a certificate has been revoked? (Providing it has not expired of course).  Do the certificate updates via Windows Update cover this? Many thanks, Regards, Darren.

• Anonymous
  September 12, 2011
  @Daz_1234: Correct, by-default, Internet Explorer on XP checks certificate revocation only for certificates used by Authenticode (e.g. signed downloads), and not for certificates used for HTTPS. That's one reason that the recent update for WindowsXP pushed the compromised DigiNotar root to the Untrusted Certificates store-- the certificate store is consulted regardless of whether or not certificate revocation is enabled or not. Similarly, earlier this year when several Comodo certificates were fraudulently issued, those individual certificates were pushed to the Untrusted Certificates store. In IE, click Tools > Internet Options > Content > Certificates and have a look at the Untrusted Publishers tab.

• Anonymous
  May 19, 2012
  @Pete: Probably because new OpenSSL versions roll outs are slow, very slow. It takes few years before such changes reach RHEL or Debian Stable. While deploying support on the client side is a matter of few months at worst.

• Anonymous
  December 04, 2013
  I wonder why the default IE behaviour on server cert revocation checks was changed in Windows Vista and later. The performance impact does not change with a newer OS, right? EricLaw As noted in the post, OCSP offers higher performance and is only available in IE on Vista+.

• Anonymous
  April 06, 2014
  Nice post Eric. I observed that in Win 7, the Certificate Revokation Check is causing extra time to load the webpages. This is due to the fact that we use PAC file for Proxy Configuration and perhaps the Certificate Revokation Check is not passing through the PAC and in turn attempts to connect to the host directly from the endpoint computer and due to firewall rules, it gets blocked and goes in retransmits. If my organization choses to disable the automation certificate revokation check, how do I ensure that I can manually update this list on a periodic basis, so as to remain secure. Are there known issues with a combination of PAC file and Certificate revokation?

• Anonymous
  June 22, 2014
  FF30 does not allow access to a secure site if the server supports OCSP Stapling and the user's computer time is in the past.  The error is sec_error_ocsp_future_response.  So users are not able to access our site simply because their time is incorrect!  I'm trying to disable OCSP Stapling on IIS7, but it will not remain off.  I added RequestOCSP of type DWORD and set it to 0 to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters but stapling turns on again the next day.   Any idea how to turn it off for good? [EricLaw] I've never heard of any problem disabling stapling, but you'll want to ask your question in an IIS forum.

• Anonymous
  February 05, 2015
  what are the consequense when server certificate revoking is unchecked? [EricLaw] If a certificate were forged or its key were stolen, you wouldn't be alerted to the attack.