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 and ails.
  • 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 renewed by the server in order to return the 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).

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 DNS, and if the attacker has control of 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).