Please read my blog's comment policy here.
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:
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:
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.
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).
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?
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?
@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.
@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.