More and more companies are using the Google Chrome browser or the new Chromium-based Microsoft Edge (codename Anaheim) on.
When distributing one of these two browsers, it should be noted that they sometimes behave differently from other browsers in terms of certificates.
Besides the fact that Chromium, unlike Internet Explorer and the previous Edge (codename Spartan) the RFC 2818 enforces, it also behaves in the Checking blocking information different.
Sometimes it is necessary for a certificate issued by a certification authority to be withdrawn from circulation even before its expiration date. To make this possible, a certification authority keeps a revocation list. This is a signed file with a relatively short expiration date, which is used in combination with the certificate to check its validity.
Soft-fail for revocation list check on the Internet offers little security - so Chrome turns it off completely
Since the availability of blocking information on the Internet often does not work satisfactorily (according to the Telemetry data from Mozilla 10% of all OCSP requests are not answered), browser manufacturers have long ago started to implement a soft-fail.
Soft-fail means that the revocation list is only validated if the revocation information is actually available. If the revocation information is not available, for example because the address stored in the CRL distribution point of the certificate is no longer correct, it is tacitly assumed - despite the fact that the revocation status cannot be determined - that the certificate is still valid and accepted accordingly.
A curiosity here is that the CryptoAPI (CAPI) used by browsers on Windows to check revocation status returns the same error code ("The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)") in the case of an expired revocation list as it does when it is unreachable - which means that expired revocation lists are also silently accepted by Internet Explorer and previous Edge.
The background to this decision was that users should not be conditioned to click away error messages - and such in the event of a hard-fail (i.e. a refusal to accept the certificate in the event that the revocation information is unavailable) - would certainly occur very frequently for sites on the Internet.
Google is now rightly of the opinion that the implementation of a soft -fail reduces security to such an extent that the entire lock check is actually pointlessand has consequently disabled it completely for the Chrome browser as of version 19:
In light of the fact that soft-fail, online revocation checks provide no effective security benefit, they are disabled by default in Google Chrome version 19 and later. By setting this policy to true, the previous behavior is restored and online OCSP/CRL checks will be performed.
https://www.chromium.org/administrators/policy-list-3#EnableOnlineRevocationChecks
If the policy is not set, or is set to false, then Google Chrome will not perform online revocation checks in Google Chrome 19 and later.
For pages on the Internet, this may well be a sensible decision, especially since with Chromes CRLSets nor an emergency option is available for major security incidents, and the Validity of SSL certificates on the Internet in general is continuously reduced (in the case of Let's Encrypt even to only 90 days).
However, since it should generally be possible to assume that the locking information is up-to-date and retrievable in the case of an internal public key infrastructure, it is usually quite desirable in this case for it to be evaluated by the participants as well.
Fortunately, it is possible to reactivate the blacklist check. The following options are available here:
- General disabling of the blacklist check (default behavior).
- General activation of the blacklist check with soft-fail in case of error.
- Selective activation of revocation list checking for certificates issued by internal certification authorities with hard-fail in case of error.
Verify the described behavior
First, we verify that the applications behave as described. For comparison, we call up an internal page with a revoked certificate (for the procedure, see the article "Revoking an issued certificate„).
Please note that revocation information is cached on Windows systems and is not updated live. Therefore, if a revocation list or OCSP response has already been obtained for the certificate authority in question before the certificate was revoked, and if this is still valid, there is no guarantee that a newly published revocation information will be retrieved before it expires. If you want to force the download of updated revocation information, the local address cache (URL cache) must be cleared. For the procedure, see the article "View and clear the revocation list address cache (CRL URL Cache).„.
Internet Explorer will correctly recognize the certificate as revoked (error code ERROR_INTERNET_SEC_CERT_REVOKED) and refuse the connection.
Google Chrome and the new Edge, however, do not check the certificate for its revocation status and accept the connection.
General activation of the revocation list check with soft-fail in case of error
If you now want Chrome to check the revocation status of certificates in principle, but continue silently in case the revocation information is not available (soft-fail), the registry setting (or group policy) "EnableOnlineRevocationChecks" (Google, Microsoft) are set:
| Browser | User or machine | Key | Data/value |
|---|---|---|---|
| Chrome | HKEY_CURRENT_USER | Software\Policies\Google\Chrome | "EnableOnlineRevocationChecks"=dword:00000001 |
| Chrome | HKEY_LOCAL_MACHINE | Software\Policies\Google\Chrome | "EnableOnlineRevocationChecks"=dword:00000001 |
| Edge (Anaheim) | HKEY_CURRENT_USER | Software\Policies\Microsoft\Edge | "EnableOnlineRevocationChecks"=dword:00000001 |
| Edge (Anaheim) | HKEY_LOCAL_MACHINE | Software\Policies\Microsoft\Edge | "EnableOnlineRevocationChecks"=dword:00000001 |
Now the Chrome browser will correctly recognize the certificate as revoked (error code NET::ERR_CERT_REVOKED).
Selective activation of revocation list checking for certificates issued by internal certification authorities with hard-fail in case of error
There is also the possibility that only certificates issued by internal certification authorities are checked for their revocation status, but then with a hard-fail if the information cannot be obtained.
When this setting is enabled, Google Chrome will always perform revocation checking for server certificates that successfully validate and are signed by locally-installed CA certificates.
https://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors
If Google Chrome is unable to obtain revocation status information, such certificates will be treated as revoked ('hard-fail').
If this policy is not set, or it is set to false, then Google Chrome will use the existing online revocation checking settings.
For this purpose, the registry setting (or group policy) "RequireOnlineRevocationChecksForLocalAnchors" (Google, Microsoft) are set:
| Browser | User or machine | Key | Data/value |
|---|---|---|---|
| Chrome | HKEY_CURRENT_USER | Software\Policies\Google\Chrome | "RequireOnlineRevocationChecksForLocalAnchors"=dword:00000001 |
| Chrome | HKEY_LOCAL_MACHINE | Software\Policies\Google\Chrome | "RequireOnlineRevocationChecksForLocalAnchors"=dword:00000001 |
| Edge (Anaheim) | HKEY_CURRENT_USER | Software\Policies\Microsoft\Edge | "RequireOnlineRevocationChecksForLocalAnchors"=dword:00000001 |
| Edge (Anaheim) | HKEY_LOCAL_MACHINE | Software\Policies\Microsoft\Edge | "RequireOnlineRevocationChecksForLocalAnchors"=dword:00000001 |
If the lock information cannot be retrieved now, the user will receive a corresponding error message (error code NET::ERR_CERT_UNABLE_TO_CHECK_REVOCATION).
Internet Explorer, on the other hand, will - since a soft-fail is implemented here after all - tacitly accept the certificate in such a case, however, as already described.
Should I enable the revocation status check?
In general, it makes sense for certificates from internal certification authorities to have their revocation status checked in most cases. The German Federal Office for Information Security (BSI) even requires this for the federal administration.
In my opinion, the only really sensible option for corporate networks is the one with hard-fail. However, this requires that the infrastructure for the locking information has a correspondingly high availability and, in the case of large environments, can also cope with the expected load (especially in the case where OCSP is used).
Related links:
External sources:
- Revocation checking and Chrome's CRL (Adam Langley)
- EnableOnlineRevocationChecks (Chromium Project)
- RequireOnlineRevocationChecksForLocalAnchors (Chromium Project)
- CRLSets (Chromium Project)
- Microsoft Edge Browser Policy Documentation (Microsoft Docs)
- Matching table for the BSI minimum standard for web browsers (German Federal Office for Information Security)
- Revocation doesn't work (Adam Langley)
- No, don't enable revocation checking (Adam Langley)
- Understanding Certificate Revocation Checks (Microsoft, archive.org)
- How Do Browsers Handle Revoked SSL/TLS Certificates? (ssl.com)
- What is the status of revocation checking in browsers? (Ryan Hurst)
English 
Deutsch
One thought on “Google Chrome und Microsoft Edge prüfen Sperrstatus von Zertifikaten nicht”
Comments are closed.