Leider ist es in letzter Zeit öfter vorgekommen, dass Zertifikate aufgrund sicherheitsrelevanter Zwischenfälle zurückgerufen werden mussten. Die Gründe dafür lagen teilweise bei den Zertifizierungsstellen selbst, teilweise bei den Besitzern der Zertifikate und hatten verschiedenste Hintergründe.
Hier zwei Beispiele:
- http://www.heise.de/security/meldung/Microsoft-stuft-gefaehrliche-Dell-Zertifikate-als-nicht-vertrauenswuerdig-ein-3028687.html [1]
- http://www.heise.de/security/meldung/Fatale-Panne-bei-Zertifikatsherausgeber-Tuerktrust-1776879.html [2]
Im PKI Standard existieren zwei Möglichkeiten um gültige Zertifikate für ungültig zu erklären: Certificate Revocation Lists (CRLs) und das Online Certificate Status Protcol (OCSP). Beide Standards haben den Vorteil, dass sie sehr weit verbreitet sind und unabhängig vom Betriebssystem funktionieren. Aber auch die Nachteile möchte ich hier nicht verschweigen: Sowohl einmal heruntergeladene CRLs wie auch OCSP Antworten haben bisweilen eine sehr lange Gültigkeitsdauer und werden – dem Standard folgend – entsprechend dieser verwendet[3]. Aus diesem Grund hat Microsoft bereits vor langer Zeit eine Möglichkeit geschaffen ein Zertifikat sofort für ungültig zu erklären ohne dabei dem Standard zu widersprechen. Diese Möglichkeit wird in Form des Containers „Untrusted Certificates“ im Zertifikatsstore des Computers sichtbar. Vereinfacht gesagt ist jedes Zertifikat, das sich in diesem Container befindet, für den betreffenden Rechner sofort ungültig (unabhängig von dem Revocation Status der sich aus CRLs oder OCSP Antworten ergibt).
Konkret können sich im Container „Untrusted Certificates“ sowohl Zertifikate wie auch Certificate Trust Lists (CTLs) befinden. Kurz zusammen gefasst sind CTLs digital signierte Listen, die Certificate Thumbprints der für ungültig erklärten Zertifikate enthalten:
Wie wird der Inhalt des Containers „Untrusted Certificates“ aktualisiert?
Grundsätzlich stehen mehrere Möglichkeiten zur Verfügung[4]
- Manuell (MMC, certutil oder PowerShell
- Mit Hilfe einer Group Policy
Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Untrusted Certificates
Hier können sowohl Zertifikate wie auch Listen, sog. “Disallowed Certificates”, importiert werden (Dateiendung .sst).
- Über Windows Update (Achtung! Dies ist nicht gleichbedeutend mit WSUS)
Systeme, die Zugriff auf Windows Update haben aktualisieren die CTLs automatisch auf diesem Weg. Grundsätzlich werden Sie diese Art von Update aber nicht in Ihrem WSUS finden. Ist jedoch eine erhöhte Bedrohung zu erwarten, wird ein Security Advisory veröffentlicht das auch einen Fix beinhalten kann. Dieser Fix wäre dann auch im WSUS zu finden, zusätzlich wird aber über den hier beschriebenen Mechanismus (siehe unten) aktualisiert. Interessanterweise erfolgt die Aktualisierung der vertrauenswürdigen Stammzertifizierungsstellen auf exakt dem gleichen Weg.
- Die Aktualisierung sog. „disconnected Environments“ (d.h. Systeme ohne Zugang zu Windows Update) ist etwas komplexer, weshalb ihr ein eigener Abschnitt gewidmet wurde.
Aktualisierung über Windows Update
Die hier beschriebene Art der Aktualisierung der Vertrauenswürdigen Stammzertifizierungsstellen und der Nicht vertrauenswürdigen Zertifikate hat nicht immer in dieser Form existiert: die unten genannten Updates vorausgesetzt, gilt sie für Windows Vista und später. Die neue Variante hat den Vorteil größerer Flexibilität, aber den Nachteil erhöhter Komplexität.
Konkret wurde mit dem Update KB 2677070 die automatische Updatefunktion eingeführt, mit dem Update KB 2813430 kam die Möglichkeit sog. „disconnected Environments“ (siehe unten) zu aktualisieren hinzu.[5]
Im einfachsten Fall haben die Systeme Zugriff auf Windows Update und werden die zur Verfügung gestellten Aktualisierungen automatisch einspielen.
Disconnected Environments
Eine kleine Herausforderung stellen sogenannte „Disconnected Environments“ dar. Damit sind Systeme gemeint, die (im Security Context des Computers) keinen Zugriff auf Windows Update haben. Auch dafür gibt es eine Lösung (https://support.microsoft.com/en-us/kb/2813430/ vorausgesetzt). Detaillierte Infos finden Sie auf https://technet.microsoft.com/en-us/library/dn265983.aspx, im Abschnitt „Redirect the Microsoft Automatic Update URL for a disconnected environment“.
Hier eine kurze Zusammenfassung des Ablaufs:
- Der Administrator lädt die CTLs (in Wirklichkeit handelt es sich um mehrere verschiedene Arten von Dateien – siehe unten) auf einem Rechner mit Zugang zu Windows Update herunter. Dieser Vorgang muss z.B. per Scheduled Task automatisiert werden, sonst bleibt die Aktualisierung eine einmalige Angelegenheit. Konkret geht es um folgende Dateien:
- authrootstl.cab – enthält eine non-Microsoft CTL
- disallowedcertstl.cab – enthält eine CTL mit nicht-vertrauenswürdigen Zertifikaten
- disallowedcert.sst – enthält ebenfalls eine Certificate Store mit nicht vertrauenswürdigen Zertifikaten
- thumbprint.crt – enthält nicht-Microsoft Root Zertifikate
- Der Ordner, der die in Schritt 1 heruntergeladenen Dateien enthält, wird als Share freigegeben oder über einen IIS veröffentlicht. Achten Sie darauf, dass der Zugriff sowohl nicht nur im Security Context des Benutzers sondern auch des Computers möglich sein muss. Sind die zu aktualisierenden Systeme nicht Mitglied einer Domäne ist ein IIS mit anonymen Zugriff vermutlich die bessere Wahl.
- Es wird ein „Custom Administrative Template[6]“ in einer Gruppenrichtlinie erstellt, welches auf den in Schritt 1 und 2 erstellten Ordner verweist. Diese Gruppenrichtlinie wird auf die Systeme angewendet.
Nach der Aktualisierung der Gruppenrichtlinie werden Sie folgenden Registry Eintrag finden:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\RootDirUrl
Wie der Name schon vermuten lässt, wird hier der in der Group Policy konfigurierte CTL Download Pfad eingetragen. Auch wenn die Einstellung „RootDirUrl“ heißt, geht es trotzdem um vertrauenswürdige Stammzertifizierungsstellen und um nicht vertrauenswürdige Zertifikate.
Folgende, im Artikel (https://technet.microsoft.com/en-us/library/dn265983.aspx) erwähnte, Registry Keys führen bisweilen zu Missverständnissen:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\EnableDisallowedCertAutoUpdate
Diese beiden Keys ermöglichen es die Aktualisierung von Root CA Zertifikaten und nicht vertrauenswürdigen Zertifikaten getrennt zu steuern, sind aber standardmäßig nicht vorhanden. Der Grund für die Einführung dieser Konfigurationsmöglichkeit war, dass Microsoft seinen Kunden die Möglichkeit geben möchte die Liste der vertrauenswürdigen CAs selbst zu definieren aber trotzdem die automatischen Aktualisierungen der nicht vertrauenswürdigen Zertifikate beziehen zu können. Wer beides gleich behandeln möchte, kann die Registry Werte DisableRootAutoUpdate and EnableDisallowedCertAutoUpdate also getrost ignorieren.
Entgegen aller Erwartungen erscheinen auch keinerlei Aktualisierungen im Certificate Store des Computers oder Benutzers, stattdessen wird die CTL als Blob (Binary Large Object) in der Registry gespeichert:
Wie kann man nun verifizieren ob die Aktualisierung erfolgreich war?
Möglichkeit 1: CAPI2 Log
Im CAPI2 Log (Sie finden es im Eventlog > Application and Services Logs > Microsoft > Windows > CAPI2) finden sich folgende Einträge, die auf eine erfolgreiche Aktualisierung hinweisen:
| Event ID 53 |
Task category: Retrieve Object from Network Keywords: Automatic Root Update |
| Event ID 20 | Task Category: Retrieve Third-Party Root Certificate from Network |
Beachten Sie unbedingt auch die Details, Event ID 53 wird auch bei „normalen“ CRL Downloads ausgelöst.
Möglichkeit 2: Certutil
Um zu sehen wann die CTLs auf einem System zuletzt synchronisiert wurden bzw. um deren Inhalt zu sehen führen Sie den folgenden Befehl aus:
certutil -getreg \SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertLastSyncTime
Das Ergebnis sollte wie folgt aussehen und das Datum der letzten Aktualisierung enthalten:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate:
DisallowedCertLastSyncTime REG_BINARY = 11/18/2015 8:00 AM
CertUtil: -getreg command completed successfully.
Um den Zeitstempel der auf einem Rechner befindlichen CTL herauszufinden, gehen Sie am besten wie folgt vor:
- Zunächst muss die CTL aus der Registry exportiert werden:#
certutil -getreg \SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertEncodedCtl | findstr /v "HKEY_LOCAL_MACHINE DisallowedCertEncodedCtl CertUtil:" | findstr 0 > disallowed.hex - Anschließend wird die Datei decodiert: certutil -decodehex disallowed.hex disallowed.ctl
- Schließlich suchen wir in der .ctl Datei nach dem Wert “ThisUpdate”: certutil disallowed.ctl | findstr ThisUpdate
- Das Ergebnis kann z.B. wie folgt aussehen: ThisUpdate: 9/23/2015 9:50 AM
Alternativ können Sie die Ausgabe auch in eine Textdatei umleiten:
certutil disallowed.ctl > disallowed.txt
Ab Windows 8 geht das in nur einem Schritt: certutil –verifyCTL disallowed | findstr ThisUpdate
Kann der Download der CTL auch manuell ausgelöst werden?
Der Registry Key HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertLastSyncTime enthält den Zeitpunkt der letzten Synchronisation. Löschen Sie diesen Eintrag entweder mit Hilfe von Regedit oder dem Befehl
certutil -delreg \SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\DisallowedCertLastSyncTime
Der Download der CTLs erfolgt erst dann, wenn die Liste der „Trusted Root CAs“ oder „Untrusted Certificates“ erstmals benötigt wird. Möchten Sie den Download manuell auslösen, können Sie z.B. einfach im Browser auf eine SSL/TLS verschlüsselte Seite surfen. Bedenken Sie, dass die Information zwischengespeichert wird, d.h. dieser Trick funktioniert nur einmal und danach erst wieder wenn der Cache geleert wurde. Alternativ können Sie auch eine beliebige Zertifikatsdatei (ohne privaten Schlüssel), die in Ihrer Umgebung nicht vertrauenswürdig ist, verwenden. Speichern Sie die Datei lokal auf einem Rechner ab und führen Sie dann folgenden Befehl aus:
certutil -verify <Dateiname>
Certutil –verify hat zunächst nichts mit dem Download von CTLs zu tun, bewirkt aber, dass die Liste der Trusted Root CAs benötigt uhd die CTLs aktualisiert werden. Die eigentliche Aufgabe dieses Kommandos ist Details zur Vertrauenswürdigkeit und dem Revocation Status eines Zertifikats zu liefern.
Alternativen?
Nicht unerwähnt soll bleiben, dass Sie alternativ auch den Zugriff auf die entsprechenden Dateien auf Windows Update freigeben könnten:
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
[1] Microsoft reagierte darauf mit folgendem Security Advisory: https://technet.microsoft.com/en-us/library/security/3119884
[2] Microsoft reagierte darauf mit folgendem Security Advisory: https://technet.microsoft.com/library/security/2798897?f=255&MSPPError=-2147217396
[3] Siehe RFC 3280: https://tools.ietf.org/html/rfc3280#section-6.3
[4] Die hier vorgestellten Möglichkeiten gelten für Windows Vista und höher.
[5] „… with KB 2677070 (https://support.microsoft.com/en-us/kb/2677070/) Microsoft introduced mechanisms in cryptographic services to check online, whenever a certificate is being validated and its chain builds up to an untrusted CA, if the CA is in the Trusted Root CA Program, and if so, it will be Added to the Trusted Root list of the machine validating the certificate.”
“Later, with KB 2813430 (https://support.microsoft.com/en-us/kb/2813430/) we provided the customers to have a repository “in house” where cryptographic service checks instead if going to http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/. Note that although the URL is hosted under the Windows Update URL this process is not related in any way with Windows Updates…”
[6] Allgemeine Informationen zu Custom Certifidate Templates finden Sie hier: https://technet.microsoft.com/en-us/library/cc738443%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396.
_1.png "You can't do today's job with yesterday's technology and be in business tomorrow (4)")
