Defective By Design? - Certificate Revocation Behavior In Modern Browsers

With the recent fraudulent certificate incident involving one of Comodo's RAs there is a renewed interest in the quality and reliability of the revocation infrastructure surrounding X.509 certificates ("SSL"). Adam Langley, a researcher at Google, coincidentally wrote a blog post entitled Revocation Doesn't Work deriding the system several days before the compromise became public knowledge. However, the situation is more complex than many have intimated.

First, some background and a description of the idealized revocation environment. Revocation in X.509 is at its core a list of certificate serial numbers that should no longer be trusted. A client asks the CA whether or not a certificate can be trusted in one of two ways.

Ways To Request Revocation Information

The first is called a certificate revocation list (CRL). CRLs are generated on a per root basis and list every serial number that has been revoked and the date they were revoked1 along with a notBefore and notAfter date for the CRL itself. Each CRL is signed by the root2 itself to allow clients to validate that the list is genuine and currently within its validity period. This allows CRLs to be distributed over HTTP by the CA3 and cached so they do not need to be re-fetched by the client constantly.

The second method by which a client can obtain revocation information regarding a certificate is via Online Certificate Status Protocol. OCSP responders accept requests that contain a serial4 and reply with a signed statement about that single certificate. This avoids the potentially large overhead of downloading a CRL and ostensibly means you can get "fresher" revocation information about a certificate5.

Idealized model

  1. A website operator decides they want to secure their shopping cart using SSL. This person heads to a certification authority (CA) and buys an SSL certificate from them for "".
  2. The CA performs validation6, issues the certificate, and the customer7 installs it on their server.
  3. Unfortunately, a few weeks later their server is hacked and the private key for that certificate is stolen.
  4. The subscriber now contacts the CA and requests revocation (and a new certificate to replace the revoked one).
  5. The CA adds the compromised certificate's serial number to their revocation list and OCSP responder.
  6. The relying party8 can rest easy knowing that their browser will now tell them if the certificate is ever seen again.


In practice there are many issues with the scenario described above. Among the biggest is that revocation information is a blocking operation. This means that you don't want to actually load anything from a site until you know the cert is trustworthy. So therefore to load any SSL secured website you need to have known valid revocation information for the certificate before you make your requests. This means that your SSL secured site's load time is dependent on the speed with which the browser can fetch revocation data from the CA's repository9. But wait, there's more! What if the CA's revocation infrastructure is unreachable? There are many reasons why it might be down: normal downtime, you're experiencing an attack and the attacker has chosen to break revocation responses, or maybe it's just over capacity. In the real world reachability and latency affect CRL/OCSP so much that browsers have been forced to ignore revocation information when unavailable. But things get even murkier if you start looking at the "types" of server certificates10.

Domain Validation (DV)

Domain validated certificates are by far the most popular (and cheapest) certificate available today. Their vetting methods vary by CA11, but they're almost entirely automated and rely on domain ownership being proven by means of a beacon (a file placed on the webserver at the domain) or receipt of an email to an acceptable list of email addresses (typically the Mozilla approved list of 5). No major browser checks CRL or OCSP on these certificate types by default. So even in our idealized situation above the relying party would not know the certificate has been revoked.

Organization Validation (OV)

Organization validated certificates are similar to DV, but they include some level of organization vetting (and subsequent inclusion of org name within the certificate fields). These certs obtain the same visual lock indicators that DV certs have in browsers so there is no way to distinguish between the two without examining the certificate itself. Again, no major browser checks CRL or OCSP on these certificate types by default. So even in our idealized situation above the relying party would not know the certificate has been revoked.

Extended Validation (EV)

The newest of the certificate types also carries by far the most comprehensive vetting procedure. Unlike the other two types, EV standards are dictated by the CABrowser Forum. EV was developed in response to the perceived degradation of validation quality (and overall certificate trust) that occurred when DV was introduced. Browsers present a different UI for EV certificates to try to demonstrate to the relying party that the site in question has undergone a higher level of validation. This UI typically shows the organization's name. Revocation is checked (CRL or OCSP, depending on browser and OS), but if the revocation server does not provide a well-formed reponse there are many possible responses depending on browser.

Browser Revocation Information Tables

Firefox 4
DVChecks OCSP if AIA is present, no CRL check
OVChecks OCSP if AIA is present, no CRL checkEVChecks OCSP (no CRL) and if no response/invalid response removes EV presentation, making it look like OV
Can turn on security.OCSP.require to true, but if the cert has no OCSP embedded it does not check CRL and proceeds without issue. Firefox will also check intermediates on DV/OV/EV if an OCSP AIA is present but does not provide UI feedback if they fail except the EV presentation removal

Firefox 4 Screenshots

Firefox EV presentation: Ff4-normal
Firefox EV when revocation data is blocked/returned as invalid: Ff4-500
DVDoes not check by default on Mac/Windows (Linux unknown)
OVDoes not check by default on Mac/Windows (Linux unknown)EVChecks and if no response/invalid response puts up a warning similar to mixed content. When moused over shows "could not check information". ONLY TRUE IN DEV/BETA CHANNEL, not stable at this time
Default checking same as Safari on Mac (controlled by parent OS prefs). On Windows presumably mediated by schannel and NSS on linux. Chrome checks the entire chain for EV (and may do it for others if the checks are enabled at the OS level)

Chrome 10 Screenshots

Chrome 10 standard EV presentation Chrome10-normal
Chrome 10 EV with default settings and the OCSP responder returning 500: Chrome10-500
Chrome 10 with OS X's "Require" turned on for EV: Chrome-bestattempt-require
DVDoes not check by default
OVDoes not check by defaultEVChecks and if no response/invalid response removes EV presentation, making it look like OV
Controlled by Keychain Access (~/Library/Preferences/ Hold option to select require for all certs on OCSP or CRL. Requiring (or even best attempt) can cause odd behavior with some other programs. This may be due to extremely large CRLs or other improper deployment of revocation infrastructure. For example, Apple's Worldwide Developer Relations CA (WWDRCA) has a 10MB CRL containing over 243,000 entries. Safari checks the entire chain for EV (and will do so for the others if checks are enabled)

Safari Mac OS X Screenshots

Safari 5 standard EV presentation Safari5.0.4-normal
Safari 5 EV with OCSP responder returning 500 Safari5.0.4-500
Safari 5 EV with OS level OCSP/CRL turned to require and OCSP/CRL returning 500 Requireall-safari-fail
DVChecks OCSP/CRL and removes the encrypted connection indicator if response fails.
OVChecks OCSP/CRL and removes the encrypted connection indicator if response fails.EVChecks OCSP/CRL and removes the encrypted connection indicator if response fails.
Opera is the most aggressive of the major browsers. The connection will be labeled unencrypted if revocation checks fail. Opera checks the entire chain if CDP/AIA is present.
Opera 11 standard EV presentation
Opera 11 EV with OCSP responder returning 500
Opera 11 Additional Detail Opera-ocsp-fail
Internet Explorer 7/8 (Windows XP)
DVChecks CRL (no OCSP support) but if request gets no response/invalid response no error/UI change occurs
OVChecks CRL (no OCSP support) but if request gets no response/invalid response no error/UI change occursEVChecks CRL (no OCSP support) but if request gets no response/invalid response no error/UI change occurs (EV presentation is NOT removed)

IE XP Screenshots

IE8 EV presentation on XP
Internet Explorer 8/9 (Windows 7)
DVChecks OCSP (with CRL fallback) but if request gets no response/invalid response no error/UI change occurs
OVChecks OCSP (with CRL fallback) but if request gets no response/invalid response no error/UI change occursEVChecks OCSP (with CRL fallback) but if request gets no response/invalid response no error/UI change occurs (EV presentation is NOT removed)

IE Win7 Screenshots

IE9 EV presentation on Windows 7


Revocation, while not broken in principle, does not work in practice. Browsers typically don't check it, and when they do they don't hard fail on no/broken response. So what do we do?

Browsers can't afford to hard fail unless revocation infrastructure is reliable, but hard fails on error are the only way to guarantee user security. This ideally means revocation data should be decentralized as much as possible12

One feasible (but not near-term) solution to partial decentralization is OCSP stapling. OCSP stapling has the server make requests to the OCSP responder, cache the response, then serve it to the client as part of the initial handshake. This lowers latency for the browser and is secure since the response is signed to prevent tampering at the server side; but OCSP stapling is not widely available at this time. Most web server software does not support it13 and browsers may not have it implemented. Additionally, OCSP stapling supports only end entity (also known as leaf) certificates and can't staple responses for intermediate certificates14.

In the near-term there are several ways browsers and CAs could begin to mitigate this security issue and improve the utility of revocation. These "fixes" all come with an attendant set of problems, but in the wake of recent events we should seriously consider whether the problems created by "fixing" revocation outweigh the advantage gained.

  • Check CRL/OCSP for all certificate types
  • In conjunction with the above, to prevent serious issues don't throw errors but degrade UI to non-SSL when unable to fetch revocation status
  • Instead of the above, hard fail and shame any non-performant CAs into improving their revocation infrastructure

In concert with this CAs would need to discuss metrics with the browser makers to determine the load (and distribution of that load worldwide) that will be experienced as well as acceptable response times, et cetera.

Another performance optimization could be found in "prefetching". At the moment OCSP and CRL checks are blocking on HTTPS connections for security reasons. To speed things up without compromising security browsers could potentially fetch data that didn't include identifiable information15 and then hold onto that data until the response came back. If it was invalid/revoked then the data can be dropped without ever being rendered/executed. This lets the browser parallelize some aspects of the connection and speed up the browsing experience without sacrificing significant security. Of course, this would only be useful in the most basic case of "GET /" without a session.

Non-Browser Utilization of SSL

This entire discussion has been concerned with the way web browsers handle HTTPS, but there are numerous other applications that make use of SSL (and even HTTPS) that are not web browsers. Email clients, mobile apps, APIs such as Java's HttpURLConnection or Ruby's Net::HTTP, command line clients like curl, and many more all rely on SSL and the vast majority do not check revocation. These should not be forgotten in the push towards greater security.


1. They can also list a revocation reason as defined in RFC 3280/5280, but this is not done by all CAs.
2. or a delegated signing key with the cRLSigning bit.
3. avoiding the circular trust issue implicit in fetching a CRL for a site from an HTTPS site that you need a CRL for...
4. far more information about what a request/response looks like is available in RFC 2560.
5. In theory CAs will provide you on-demand revocation information via OCSP rather than generating only once per X hours/days like CRL.
6. The extent of this validation varies dramatically by certificate type. A subject for another time.
7. now known as the subscriber in CA parlance.
8. CA parlance for the website user rather than the website owner. When you visit you are a relying party.
9. For those who are interested, you need to get the SERVER HELLO to obtain the certificate, parse it to obtain the CDP or OCSP AIA, then make a roundtrip to that server and parse that response before proceeding.
10. For the purposes of today's discussion we will not be talking about code signing, S/MIME certificates, or any of the more esoteric EKUs.
11. Check the Certification Practice Statement (CPS) for the certificate for details on how each CA does it.
12. You could also, as Langley has suggested, shorten certificate lifetimes sufficient to remove the need for revocation. This does introduce new requirements for automated installation on servers and enforces a lower bound on CA issuance reliability.
13. ~3% of servers currently support it. IIS8 and Apache in 2.3 trunk.
14. Opera has proposed an extension that will remedy this lack.
15. A query string or POST data could potentially leak data to an attacker, so sending such a request would be inadvisable.

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.