Checking the revocation status of SSL/TLS certificates presented by HTTPS websites is an ongoing problem in web security. Unless a server is configured to use OCSP Stapling, online revocation checking by web browsers is both slow and privacy-compromising. Because online OCSP queries fail so often and are impossible in some situations (such as with captive portals), browsers generally implement OCSP checking in “soft-fail” mode, rendering it ineffective at deterring a determined attacker. (For a more complete history of this issue, please read SSL.com’s article, Page Load Optimization: OCSP Stapling).
For these reasons, web browsers have implemented a range of solutions to reduce or eliminate the need for online revocation checking. The exact details vary between providers, but these solutions generally involve harvesting lists of revoked certificates from certificate authorities (CAs) and pushing them to browsers.
This article provides high-level summaries of the validation-checking strategies employed by major browsers (Chrome, Firefox, Safari, and Edge), and compares the responses of these browsers to some sample revoked certificates hosted by SSL.com.
Chrome relies on CRLSets for revocation checking. A CRLSet is simply a list of revoked certificates which is pushed to the browser as a software update. According to the Chromium Projects website, the processes by which Google generates CRLSets are proprietary, but also that
CRLSets… are primarily a means by which Chrome can quickly block certificates in emergency situations. As a secondary function they can also contain some number of non-emergency revocations. These latter revocations are obtained by crawling CRLs published by CAs.
The above statement indicates that at least some low-priority revoked end-entity certificates could end up in CRLSets, but that they are a secondary consideration.
You can check the CRLSet version currently installed in an instance of Chrome by navigating to
It is not currently possible to directly configure Chrome to perform online certificate validity queries. However, depending on the operating system, these checks may be performed by the underlying certificate library used by the OS. (As can be seen below in the results from limited browser tests, we found that installations of Chrome with the same version number and CRLSet actually responded to one revoked certificate differently on Windows versus macOS.)
Like Google, Mozilla maintains a centralized list of revoked certificates, called OneCRL. OneCRL is a list of intermediate certificates that have been revoked by CAs in Mozilla’s root program, and is pushed to Firefox users in application updates. Regarding end-entity certificates, Mozilla’s revocation plan notes that “In the future, once the initial implementation is working, we may look into covering EE certificates with OneCRL, possibly focusing initially on specific classes (e.g., EV certificates).”
Unlike Chrome, Firefox’s default settings also query OCSP responders to confirm the validity of SSL/TLS certificates. (You can change this setting in Firefox’s security preferences.)
However, because OCSP query failures are so common, Firefox (like other browsers) implements a “soft-fail” policy. If you wish, you can require strict OCSP checking by navigating to
about:config and toggling
Apple’s current approach to revocation is covered by Bailey Basile in her 2017 WWDC talk, Your Apps and Evolving Network Security Standards. Apple collects certificate revocation information from the CAs that are trusted on its devices and aggregates it all into a single bundle that is periodically retrieved by Apple’s client software (sound like a familiar plan yet?).
When a client application encounters a certificate that is shown in Apple’s list, it performs an OCSP check to confirm that the certificate is, in fact revoked (unless the server provides a stapled OCSP response). Note that online OCSP checks are only done in the case of certificates that Apple already thinks are revoked; certificates that are not listed in the bundle retrieved from Apple are not checked.
A link to Apple’s revocation list and code for parsing it is available here.
Windows maintains a list of revoked or otherwise blacklisted certificates in a file called
disallowedcert.stl. This blog entry provides information on dumping the file’s contents with PowerShell. crt.sh also provides information as to whether a particular certificate is listed in
Like Firefox, Windows is set to check for certificate revocation by default, and this setting carries over to the Explorer and Edge browsers. This setting can be viewed and changed in the Internet Properties control panel:
However, the current Chromium-based beta version of Edge, like Chrome, relies on CRLSets for revocation checking and (at least at present) appears from our tests below to be independent of revocation-checking settings in Internet Properties.
Variation Between Browsers
Since SSL.com maintains a group of web servers hosting sample revoked certificates, we decided to test them against a range of desktop browsers.This small, not terribly scientific test was carried out on September 10, 2019. The browsers used were:
- Chrome 76.0.3809.132, CRLSet version 5390 (macOS 10.14.6)
- Chrome 76.0.3809.132, CRLSet version 5390 (Windows 10 Enterprise)
- Firefox 69.0 – OCSP queries on (macOS 10.14.6)
- Firefox 69.0 – OCSP queries off (macOS 10.14.6)
- Safari 12.1.2 (macOS 10.14.6)
- Edge 44.17763.1.0 (non-Chromium) (Windows 10 Enterprise)
- Edge 22.214.171.124 beta (Chromium) (Windows 10 Enterprise)
In addition, we tested Chrome and both the production and beta versions of Edge in Windows with online revocation checking disabled in the Internet Properties control panel, and (for Chrome, Firefox, and Edge) checked if the relevant certificate was listed as revoked with a particular browser program in crt.sh. For reasons of space those results are omitted from the table below, but are mentioned in the discussion section that follows.
|Chrome (macOS)||Chrome (Windows)||Firefox (OCSP on)||Firefox (OCSP off)||Safari||Edge||Edge (Chromium)|
|revoked-rsa-dv.ssl.com||Revoked||Not Revoked||Revoked||Not Revoked||Revoked||Revoked||Not Revoked|
Discussion of Results:
Chrome: On Windows, Chrome incorrectly showed one of the revoked certificates (revoked-rsa-dv.ssl.com) as valid and the others as revoked. Disabling validation checking in the OS did not alter this response. Interestingly, none of the four certificates were shown as revoked in CRLSet in crt.sh at the time of the test, suggesting further questions about Chrome’s revocation checking processes. On macOS, Chrome correctly showed all four certificates as revoked, illustrating platform-based differences in Chrome’s behavior.
Firefox: As might be expected from OneCRL’s stated focus on intermediate certificates, Firefox recognized all four certificates as revoked with OCSP queries enabled in the browser’s preferences, but accepted all four as valid if OCSP queries were disabled. (Note: All four of these revoked end-entity certificates were issued from valid, non-revoked intermediates.) As with Chrome, crt.sh shows none of the certificates as revoked in OneCRL.
Safari: Safari on macOS correctly recognized all four certificates as revoked. crt.sh does not display Apple revocation information, and we did not check to see if these particular certificates are listed as revoked by Apple.
Edge: The current production version of Edge, which uses Microsoft’s EdgeHTML and Chakra engines, correctly recognized all four certificates as revoked. However, when revocation checks were disabled in the OS, all four certificates were shown as valid. None of the four certificates were shown as listed in
disallowedcert.stl on crt.sh. The Chromium-based beta version of Edge mirrored Chrome in showing revoked-rsa-dv.ssl.com as valid. Like Chrome, the Edge beta showed the same results whether or not validation checking was enabled in the OS.
The results appear to indicate that revocation is still a problematic issue for desktop web browsers (mobile devices represent a whole different world, but that’s a topic for another article). Enabling (slow, insecure) online OCSP checking was necessary to recognize certificates as revoked in Firefox and (non-Chromium) Edge, while Chrome and the Chromium-based Edge beta failed to recognize a revoked certificate on Windows whether or not revocation checking was enabled in the OS.
For website owners, it seems wise to assume that the various browser programs are focused on high-priority/emergency incidents such as revoked root and intermediate CA certificates, and that revocations of garden-variety end-entity certificates are likely to pass unnoticed for an indefinite period. For this reason, implementing OCSP Stapling and Must-Staple appears to be the most private, secure, and effective way to ensure that end users receive accurate information on revocation of end-entity certificates.
Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.