Immer mehr Unternehmen setzen als Standardbrowser auf der Windows-Plattform den Google Chrome Browser oder den neuen auf Chromium basierenden Microsoft Edge (Codename Anaheim) ein.
Bei der Verteilung eines dieser beiden Browser sollte beachtet werden, dass sie sich in Hinsicht auf Zertifikate teils abweichend zu andere Browsern verhalten.
Nebst der Tatsache, dass Chromium im Gegensatz zum Internet Explorer und dem vorigen Edge (Codename Spartan) das RFC 2818 erzwingt, verhält er sich auch bei der Prüfung von Sperrinformationen anders.
Mitunter ist es erforderlich, dass ein von einer Zertifizierungsstelle ausgestelltes Zertifikat bereits vor dessen Ablaufdatum aus dem Verkehr gezogen werden muss. Um dies zu ermöglichen, hält eine Zertifizierungsstelle eine Sperrliste vor. Hierbei handelt es sich um eine signierte Datei mit einem relativ kurzen Ablaufdatum, welches in Kombination mit dem Zertifikat zur Überprüfung der Gültigkeit herangezogen wird.
Soft-fail für Sperrlistenprüfung im Internet bietet kaum Sicherheit – also schaltet Chrome sie komplett ab
Da die Verfügbarkeit von Sperrinformationen im Internet oftmals nicht zufriedenstellend funktioniert (laut den Telemetriedaten von Mozilla werden immerhin 10% aller OCSP-Anfragen nicht beantwortet), sind Browserhersteller schon vor langer Zeit dazu übergegangen, einen Soft-fail zu implementieren.
Soft-fail bedeutet, dass eine Validierung der Sperrliste nur dann stattfindet, wenn die Sperrinformation auch tatsächlich verfügbar ist. Sollte die Sperrinformation nicht abrufbar sein, etwa weil die im CRL Distribution Point des Zertifikats hinterlegte Adresse nicht mehr stimmt, wird – trotz dass der Sperrstatus nicht ermittelt werden kann – stillschweigend angenommen, dass das Zertifikat noch gültig ist und es entsprechend akzeptiert.
Ein Kuriosum hierbei ist, dass die von den Browsern auf Windows zur Prüfung des Sperrstatus verwendete CryptoAPI (CAPI) im Falle einer abgelaufenen Sperrliste den gleichen Fehlercode ("The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)") zurückgibt wie im Falle, dass sie nicht erreichbar ist – was dazu führt, dass abgelaufene Sperrlisten vom Internet Explorer und vorigen Edge ebenfalls stillschweigend akzeptiert werden.
Hintergrund dieser Entscheidung war, dass Benutzer nicht auf das wegklicken von Fehlermeldungen konditioniert werden sollten – und solche im Falle eines Hard-fail (also eine Verweigerung der Akzeptanz des Zertifikats im Falle der Nichtverfügbarkeit der Sperrinformation) – für Seiten im Internet sicherlich sehr häufig auftreten würden.
Google ist nun zu Recht der Meinung, dass die Implementierung eines Soft -fail die Sicherheit derart reduziert, dass die gesamte Sperprüfung eigentlich sinnlos ist, und hat diese folgerichtig für den Chrome Browser ab Version 19 komplett abgeschaltet:
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.
Für Seiten im Internet mag dies durchaus eine sinnvolle Entscheidung sein, zumal mit Chromes CRLSets noch eine Notfall-Option für größere Sicherheitsvorfälle zur Verfügung steht, und die Gültigkeit von SSL-Zertifikaten im Internet allgemein kontinuierlich reduziert wird (im Falle von Let’s Encrypt sogar auf nur noch 90 Tage).
Da man bei einer internen Public Key Infrastruktur im Regelfall jedoch davon ausgehen können sollte, dass die Sperrinformationen aktuell und abrufbar sind, ist es in diesem Fall meist durchaus wünschenswert, dass diese auch von den Teilnehmern ausgewertet werden.
Glücklicherweise besteht die Möglichkeit, die Sperrlistenprüfung wieder zu aktivieren. Folgende Möglichkeiten bieten sich hierbei an:
- Generelle Deaktivierung der Sperrlistenprüfung (Standardverhalten).
- Generelle Aktivierung der Sperrlistenprüfung mit Soft-fail im Fehlerfall.
- Selektive Aktivierung der Sperrlistenprüfung für von internen Zertifizierungsstellen ausgestellte Zertifikate mit Hard-fail im Fehlerfall.
Verifizieren des beschriebenen Verhaltens
Zunächst verifizieren wir, ob sich die Anwendungen überhaupt wie beschrieben verhalten. Zum Vergleich rufen wir eine interne Seite mit einem widerrufenen Zertifikat auf (zur Vorgehensweise siehe Artikel "Widerrufen eines ausgestellten Zertifikats").
Bitte beachten, dass Sperrinformationen auf Windows-Systemen zwischengespeichert werden und nicht live aktualisiert werden. Wurde also bereits vor Widerruf des Zertifikats eine Sperrliste oder OCSP-Antwort für die betreffende Zertifizierungsstelle bezogen, und ist diese noch zeitgültig, ist nicht garantiert, dass vor deren Ablauf bereits eine neu veröffentliche Sperrinformation abgerufen wird. Möchte man den Download einer aktualisierten Sperrinformation erzwingen, muss hierzu der der lokale Adress-Zwischenspeicher (URL Cache) gelöscht werden. Für die Vorgehensweise siehe Artikel "Den Adress-Zwischenspeicher für Sperrlisten (CRL URL Cache) einsehen und löschen".
Der Internet Explorer wird das Zertifikat korrekt als widerrufen erkennen (Fehlercode ERROR_INTERNET_SEC_CERT_REVOKED) und die Verbindung verweigern.
Google Chrome und der neue Edge hingegen prüfen das Zertifikat jedoch nicht auf seinen Sperrstatus und akzeptieren die Verbindung.
Generelle Aktivierung der Sperrlistenprüfung mit Soft-fail im Fehlerfall
Möchte man nun bewirken, dass Chrome grundsätzlich eine Prüfung des Sperrstatus von Zertifikaten vornimmt, im Fall von Nichtverfügbarkeit der Sperrinformation jedoch stillschweigend fortfährt (Soft-fail), kann die Registrierungs-Einstellung (oder Gruppenrichtlinie) "EnableOnlineRevocationChecks" (Google, Microsoft) gesetzt werden:
| Browser | Benutzer oder Maschine | Schlüssel | Daten/Wert |
|---|---|---|---|
| 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 |
Nun wird der Chrome Browser das Zertifikat korrekt als widerrufen erkennen (Fehlercode NET::ERR_CERT_REVOKED).
Selektive Aktivierung der Sperrlistenprüfung für von internen Zertifizierungsstellen ausgestellte Zertifikate mit Hard-fail im Fehlerfall
Es gibt auch die Möglichkeit, dass nur Zertifikate, die von internen Zertifizierungsstellen ausgestellt wurden auf ihren Sperrstatus überprüft werden, dann jedoch mit einem Hard-fail, sollte die Information nicht bezogen werden können.
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.
Hierfür kann die Registrierungs-Einstellung (oder Gruppenrichtlinie) "RequireOnlineRevocationChecksForLocalAnchors" (Google, Microsoft) gesetzt werden:
| Browser | Benutzer oder Maschine | Schlüssel | Daten/Wert |
|---|---|---|---|
| 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 |
Sollte die Sperrinformation nun nicht abgerufen werden können, wird der Benutzer eine entsprechende Fehlermeldung (Fehlercode NET::ERR_CERT_UNABLE_TO_CHECK_REVOCATION) erhalten.
Der Internet Explorer hingegen wird – da hier schließlich ein Soft-fail implementiert ist – in einem solchen Fall wie bereits beschrieben jedoch stillschweigend das Zertifikat akzeptieren.
Sollte ich die Sperrstatus-Überprüfung aktivieren?
Generell ist es für Zertifikate von internen Zertifizierungsstellen in den meisten Fällen sinnvoll, dass deren Sperrstatus überprüft wird. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) verlangt dies sogar für die Bundesverwaltung.
Die einzig wirklich sinnvolle Option für Unternehmensnetzwerke ist meiner Meinung nach die mit dem Hard-fail. Diese erfordert jedoch, dass die Infrastruktur für die Sperrinformationen eine entsprechend hohe Verfügbarkeit aufweist und im Falle großer Umgebungen auch der zu erwartenden Last (besonders im Fall, wenn OCSP eingesetzt wird) gewachsen ist.
Weiterführende Links:
Externe Quellen:
- Revocation checking and Chrome’s CRL (Adam Langley)
- EnableOnlineRevocationChecks (Chromium Projekt)
- RequireOnlineRevocationChecksForLocalAnchors (Chromium Projekt)
- CRLSets (Chromium Projekt)
- Microsoft Edge Browser Policy Documentation (Microsoft Docs)
- Abgleichstabelle zum Mindeststandard des BSI für Web-Browser (Bundesamt für Sicherheit in der Informationstechnik)
- 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)
Deutsch 
English
Ein Gedanke zu „Google Chrome und Microsoft Edge prüfen Sperrstatus von Zertifikaten nicht“
Kommentare sind geschlossen.