Überprüfe die PKI – so geht’s

Eine Public Key Infrastructure (PKI) ist eine langlebige IT-Komponente und stellt zudem die Basis für Authentizität, Integrität und Verschlüsselung dar. Sie sollte die vielen Jahre über regelmässig gepflegt und an die aktuellen und künftigen Anforderungen angepasst werden.

Das betrifft die Anforderungen an die PKI, die sich ändern können, Updates die speziell für die Active Directory Certificate Services sind und eingespielt werden müssen, Konfigurationen die überprüft werden sollten und die Maintenance der Server, der Datenbank und der Certificate Templates. Hier geben wir einen kleinen Einblick in die wichtigsten Punkte.

Was ist nun wichtig?

Eine ehrliche Antwort auf die Frage: Konnte ein Admin oder sonst ein User oder gar ein Angreifer den Private Key der Certificate Authority (CA) «mitnehmen»? Die Antwort muss klar NEIN heissen. Jeder Zweifel und jede Möglichkeit muss eigentlich ein Re-Deployment der PKI bedeuten. Ein Hardware Security Module stellt, bei korrekter Verwendung, diese Sicherheit über diesen langen Zeitraum her.

Das regelmässige Aktualisieren der CRL von der RootCA und das Erneuern der CA-Zertifikate sollte man via Monitoring im Blick behalten.

Wer hat Zugriff auf das CA Management und kann Zertifikate ausstellen? Mitglieder der Gruppen prüfen und die Berechtigungen auf den Certificate Templates checken sind regelmässig durchzuführen. Eine geringe Zahl der Certificate Templates macht auch das IT-Admin-Leben leichter.

Ein Administrator der Zertifikate ausstellt, ist für die eindeutige Identifizierung des Antragsstellers verantwortlich. Insbesondere wenn Automatismen oder Service-Komponenten eingesetzt werden, ist diese Identifizierung schwierig und der Einsatz nur unter restriktiven Massnahmen zu verantworten.

Bei Smart Card Enrollment Agent oder Code-Signing-Zertifikaten ist es ja noch recht klar, da diese explizit für definierte Personen und sicher doch auf entsprechender Hardware zur Verfügung gestellt werden. Oder etwa nicht?

Bei Zertifikaten für Mobile Devices via NDES (Network Device Enrollment Service) sieht die Sache da schon anders aus. Das Password für NDES wird schon lange nicht mehr individuell an einen Router oder Switch-Admin ausgegeben, sondern der Service nutzt dies automatisch. Der Private Key des NDES Servers ein Enrollment Agent könnte missbraucht werden und gehört auf ein HSM.

Zum Backup einer Zertifizierungsinstanz gehören die Setup- und Konfiguration-Scripts, natürlich auch das CA Certificate mit Private Key, die Konfiguration und die CA-Datenbank selbst.

Besser findet man das hier:

https://www.gradenegger.eu/en/create-a-backup-of-a-certification-body/ oder

https://www.pkisolutions.com/adcsbackups/

https://www.pkisolutions.com/backing-up-adcs-certificate-authorities-part-2-of-2/

Ein Backup der Datenbank, in welcher auch die Transaction Logs bereinigt werden, ist nicht nur wichtig bei der Wiederherstellung, sondern reduziert auch die Disk Usage. Bei einer DB von mehreren GB ist das durchaus relevant.

Für die Wiederherstellung ist das Backup mit dem richtigen SMTP Auditing zu kombinieren, damit alle Zertifikate bis zum Crash und nicht nur bis zum letzten Backup wiederhergestellt werden können und somit auch für das Revoking zur Verfügung stehen.

Durch die Ergänzung des SMTP Auditing Scripts kann man das Backup der CA DB durch folgende Ergänzung optimieren.

certutil -setreg exit\smtp\templates\default\Issued\BodyArg +“RawCertificate“

Certutil -setreg exit\smtp\templates\default\Issued\BodyFormat +“Raw Certificate: %%11″

Ein regelmässiger Test des Backups – Wiederherstellung – ist nicht nur eine gute Verifizierung des Backups, sondern hilft auch die Prozesse zu üben und damit, im Falle des Falles, zügig zum Ergebnis zu kommen.

Das Entschlacken der Datenbank von Zertifikaten, die schon längst abgelaufen sind und nicht mehr «revoked» werden müssen, reduziert das Wachsen des Datenbank-Files und beschleunigt Backup und Restore. Im Falle einer korrupten Datenbank wird auch eine Offline-Defragmentierung oder ein Integrity Check so in vertretbaren Zeiten erledigt sein.

certutil -deleterow …

https://www.gradenegger.eu/de/massenhaftes-loeschen-von-eintraegen-in-der-zertifizierungsstellen-datenbank-zertifikate-anforderungen-sperrlisten/

Also abgelaufene oder auch Failed Request löschen. Wenn sehr viele fehlgeschlagene Anfragen existieren, muss man dem nachgehen und die Konfiguration der Certificate Templates oder die Certificate Requests prüfen.

CA -config «ca-server\CA Name» -getreg CA\

Viel sollte hier nicht zu machen sein, SHA-1 ist seit 2015 nicht mehr empfohlen und eine CA sollte SHA-2 mit SHA384 verwenden. Schlüssellängen sollten seit 2023 mehr als 3000 Bit sein und der Private Key sollte «safe» sein, also auf einem HSM.

Auch wenn es sicher noch etwas dauern wird die aktuellen Algorithmen zu knacken, mit dem «Peter Shor»-Algorithmus kann es für RSA und ECC gefährlich werden und mit dem «Grover»-Algorithmus sind Hash-Verfahren und auch AES angreifbar, wenn die Quantencomputer leistungsfähig genug sind. Die neue Algorithmen stehen zwar vor der Tür, aber ohne NIST-Empfehlung, die erst Mitte 2024 kommen soll, und die praktische Implementierung in die Betriebssysteme der Hersteller, was sicher auch nochmals mindestens 2-3 Jahre dauern wird, müssen wir die Zügel kurz fassen und die Möglichkeiten nutzen, die aktuell gegeben sind.

Vor allem die Web-Server, die die CRL-, OCSP- oder die CA-Zertifikate hosten, sollten nicht manipulierbar sein.

Die Konfiguration der Zertifikatsvorlagen (Certificate Templates) ist eine komplexe Angelegenheit. Bei fehlerhafter und vor allem zu lockerer Gestaltung, um es uns im Operativen leicht zu machen, können grosse Türen für Angriffe geöffnet werden. Wie immer gilt: Lieber «most restrictive», wenn es auch mühsamer ist.

SHA-2 und RSAS mit 4096 Bit basierend auf dem KSP sind, wenn immer möglich, zu verwenden. Aber ein TPM schafft halt nur 2048 Bit. Aber vor allem Subject, Subject Alternate Name und die Enhanced Key Usages sind genau zu prüfen

Nicht nur die allgemeinen OS Updates sind wichtig, sondern vor allem die spezifischen Hotfixes für die Active Directory Services müssen eingespielt werden.

https://www.pkisolutions.com/2022hotfixes/

Client-Zertifikate müssen neu ausgestellt werden und haben folgende Erweiterung:

Beispiel CRL Update

1 -2 -3- 4

Email alert

Threat detected

Threat details

Wir brauchen die Zertifikate und verlassen uns auf deren Sicherheit, deshalb muss auch die Infrastruktur zum Erstellen der Zertifikate gepflegt und vertrauenswürdig sein. Es gehört eine Menge Know How und Zeit dazu dieser Aufgabe gerecht zu werden. Es ist sicherlich gut verschiedene Aspekte zu diskutieren und abzuwägen, welche Massnahmen die Richtigen sind. Technische Lösungen können helfen, den Finger in die Wunde zu legen und Herausforderungen schnell und umfassend zu erkennen.

Im neuen Gartner Dokument “Effectively Manage Your Organization’s Certificates“ wird das Posture Management einer PKI explizit erwähnt. Es gilt nicht nur die Zertifikate zu managen, sondern vor allem auch die Basis, die Infrastruktur, dafür kontinuierlich und zuverlässig zu sorgen.