Test-CertificateStore
Heute geht nichts mehr ohne SSL und HTTPS. Für den Administrator bedeutet das natürlich, dass er sich über die Verwaltung der Zertifikate auf jedem Computer und Server Gedanken machen muss. Auch bei Troubleshooting von TLS-Verbindungen ist immer wieder ein Blick in die Zertifikate erforderlich. Daraus ist das folgende Skript entstanden, welches die Zertifikate auf dem lokalen Windows Computer prüft, einen Status meldet und ggfls. sogar zumindest abgelaufene Zertifikate gleich entsorgt.
Checks
Das Skript ist für einen interaktiven Aufruf vorgesehen. Es kann aber auch "still" in ein Monitoring eingebunden werden und liefert neben den Bildschirmausgaben mit Write-Host auch einen Status zur weiteren Auswertung zurück. Folgende Checks sind im Moment implementiert.
Stammzertifikate
Checks auf Ebene der Stammzertifizierungszertifikate.
- Ungültige Root-Zertifikate "cert:\localmachine\root
"
Im Stammzertifikatsspeicher des Computers sollten Zertifikate stehen, bei denen "Issuer" und das "Subject" identisch sind. Andere Zertifikate haben hier nichts verloren sondern sind entweder "Intermediate" oder Computerzertifikate. Natürlich müssen diese Zertifikate gültig sein. - Größe des Root-Zertifikatspeicher
Zudem sollte die Liste der RootCAs nicht mehr als 16kByte groß sein, da ansonsten Clients eventuell sich nicht mit Zertifikaten anmelden können. Siehe dazu auch Max RootCA, oder wo Vertrauen schadet. Dazu addiert das Skript vereinfach die Byte-Größe der Zertifikate und die Anzahl zusammen und spricht ggfls. eine Warnung aus. Wenn sich keinen Clients per Zertifikat anmelden, dann ist die Grenze nicht kritisch. - RootCAs sollte keinen Private Key haben.
Das ist per Definition eine Fehlkonfiguration und maximal für Analyse-Tools wie "Fiddler" erforderlich. Überrascht war ich schon, dass ich auf meinem PC dann tatsächlich ein Root-Zertifikat samt exportierbarem Private-Key gefunden habe. Ich hatte da natürlich zuerst an einen Fehler in meinem Skript gedacht aber letztlich konnte ich die Angaben bestätigen.
Gerade die Root-CAs sollten ein besonderes Vertrauen genießen und daher seriös eingesetzt werden.
- ADV180029 | Inadvertently Disclosed
Digital Certificates Could Allow Spoofing
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180029 - Microsoft warns about two apps that
installed root certificates then leaked the
private keys
https://www.zdnet.com/article/microsoft-warns-about-two-apps-that-installed-root-certificates-then-leaked-the-private-keys/ - 34C3: Das besondere Anwaltspostfach beA
als besondere Stümperei
https://www.heise.de/newsticker/meldung/34C3-Das-besondere-Anwaltspostfach-beA-als-besondere-Stuemperei-3928474.html - beA muss vorerst offline bleiben –
Sicherheit und Datenschutz haben Priorität
https://www.brak.de/fuer-journalisten/pressemitteilungen-archiv/2017/presseerklaerung-15-2017/ - CVE-2018-17612 Sennheiser HeadSetup
7.3.4903 places Certification Authority (CA)
certificates into the Trusted Root CA store
https://nvd.nist.gov/vuln/detail/CVE-2018-17612
https://www.secorvo.de/publikationen/headsetup-vulnerability-report-secorvo-2018.pdf - Sennheiser Headset Software Could Allow
Man-in-the-Middle SSL Attacks
https://www.bleepingcomputer.com/news/security/sennheiser-headset-software-could-allow-man-in-the-middle-ssl-attacks/
Die so ermittelten Stammzertifikate werden in einer Hashtabelle mit ihrem DN gespeichert, damit ich später die Intermediate-Zertifikate prüfen kann.
Intermediate Zertifikate
Die Zertifikate der Zwischenzertifizierungsstellen werden ebenfalls einem Check unterzogen.
- Keine Root/SelfSigned Cert
Ein Intermediate Zertifikate ist immer von einer anderen CA ausgestellt. Daher kann der "Issuer" und das "Subject" nicht gleich sein. - Gültigkeit der Zertifikate
Natürlich muss auch die Gültigkeitszeit dieser Zertifikate passen und wenn Sie kurz vor dem Ablaufen sind, wird eine Warnung erstellt - Existenz des passenden RootCerts
Damit in Intermediate Zertifikate funktioniert, muss es natürlich von einer vertrauenswürdigen RootCA ausgestellt worden sein. Da passt es gut, dass die Root-Zertifikate im vorherigen Schritt schon erfasst wurde.
Hier gibt es die Einschränkung, dass ich nur das Subject prüfe und es durchaus mehrere unterschiedliche Zertifikate mit dem gleichen Subject geben kann.
Die meisten Fehlkonfigurationen sollten damit gefunden werden. Allerdings muss man hier auch etwas sensibel vorgehen, denn anscheinend ist selbst Microsoft hier nicht perfekt.
In meinem "Intermediate Store" finde ich zumindest zwei Root-Zertifikat, die nach meiner Einschätzung dort nichts verloren haben:
Computerzertifikate
Zuletzt schaue ich mir die Zertifikate im Computer-Store an.
- Ausstellende CA
Jedes Zertifikat, welches in dem Store ist, sollte von einer Intermediate oder Root CA ausgestellt worden sein. Daher erfolgt bei den Zertifikaten eine Kontrolle des Issuer gegen die in der Hashtabelle gesammelte Liste der Intermediate und Root-Zertifikate. - PrivateKey vorhanden
Ein Zertifikat ohne privaten Schüssel ist eigentlich nicht sinnvoll nutzbar. - Gültigkeitszeitraum
Auch wird geprüft, ob die Zertifikat schon abgelaufen sind oder bald ablaufen. - Fremde Zertifikate
Hier sollten natürlich keine Intermediate oder Root-Zertifikate enthalten sein. Das ist aber nicht ganz einfach, das "SelfSigned"-Zertifikat nicht direkt von "Root-Zertifikaten" unterscheiden sind.
Insofern kann ich zwar schon viele Probleme erkennen aber es bleibt eine gewisse Unsicherheit.
Skript
Anbei das Skript zur freien Verwendung:
Einfach in einer PowerShell aufrufen und die Ergebnisse betrachten.
Ergebnisse
Die Ausgaben des Skript landen allesamt auf der Konsole. Allerdings sammle ich natürlich alle Warnungen, kritischen Dinge und Fehler und liefere die am Ende einfach also Liste aus.
Wie Sie die Ausgabe später weiter verarbeiten, bleibt ihnen überlassen
Weiterentwicklung
Kein Skript ist perfekt. Ich habe oben bei den Tests schon geschrieben, welche Checks noch nicht perfekt sind. Daher gibt es durchaus raum für mehr. Meine ToDo-Liste wäre
- Blocklist: Suchen nach "unerwünschten"
Zertifikaten
Man könnte eine Blocklist mitführen, die Zertifikate anhand ihres CN entfernt. Damit könnte man z.B. die Intel-, BeA- und Sennheiser-Zertifikate entfernen. - Allowlist: Kontrolle auf Existenz der
Firmen-RootCA
Vielleicht möchten Sie bestimmte RootCAs auch auf allen PCs haben. Eine Gruppenrichtlinie stellt dies für Mitglieder der Domäne einfach sicher. Aber was ist mit Clients, die damit nicht versorgt werden? - Papierkorb
Wenn ein Zertifikat zurückgezogen wird oder verfallen ist, wird es dennoch nicht aus dem Zertifikatsspeicher gelöscht. Das ist durchaus sinnvoll um z.B. verschlüsselte Mails auch noch später zu öffnen oder wenn Sie das Zertifikat doch noch verlängern wollen. Auf der anderen Seite könnten aber z.B. Computerzertifikate, die nur zur Identifizierung des Computers genutzt werden, in der Regel einfach entfernt werden - Unterscheidung von "echten Root-Zertififkaten" von
falschen "Self-Signed" Zertifikaten
Bei beide Zertifikaten ist der Aussteller und der Inhaber identisch. Eine Unterscheidung könnte die Gültigkeitsdauer sein, um echte Root-Zertifikate zu erkennen. Auch ein Check gegen eine vorgefertigte Allowlist wäre denkbar - Schwache Zertifikate
Zuletzt könnte das Skript auch noch Zertifikate heraus fischen, die einfach zu kurze Schlüssellängen oder schwache Krypto-Verfahren nutzen. Solche Zertifikate bekommen Sie natürlich nicht mehr von öffentlichen CAs aber die ein oder andere interne PKI kann immer noch veraltet sein.