Wiederherstellen von Zertifikaten aus den Daten des SMTP Exit Moduls

Stellt man eine Zertifizierungsstelle nach einem Katastrophenfall aus einer Sicherung (Backup) wieder her, wird man vermutlich feststellen, dass Zertifikate in dem Zeitraum zwischen der letzten Sicherung und dem Ausfall des Systems mit entsprechendem Datenverlust ausgestellt worden.

Diese Zertifikate sind nun nicht in der wiederhergestellten Zertifizierungsstellen-Datenbank gespeichert, somit können sie im Bedarfsfall auch nicht wiederhergestellt werden.

Hat man das SMTP Exit Modul im Einsatz, kann man aus den versendeten E-Mails wenigstens die Seriennummern der Zertifikate ermitteln und diese widerrufen.

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.

Grundlage für die erfolgreiche Wiederherstellung einer Zertifizierungsstelle im katastrophenfall ist, dass eine funktionierende Sicherung (Backup) vorliegt. Wie diese erstellt wird ist im Artikel "Eine Sicherung (Backup) einer Zertifizierungsstelle erstellen" beschrieben.

Anstelle des SMTP Exit Moduls wäre es auch möglich, ein eigenes Exit Modul zu entwickeln, welches die Zertifikate beispielsweise ins Dateisystem schreibt (auf einem entfernten Server oder in Verbindung mit einer DFS Replikation) oder in eine externe Datenbank hochlädt.

Vorgehensweise

Prüfung, ob die Seriennummer schon vorhanden ist

Zunächst sollte geprüft werden, ob die Seriennummer schon in der Zertifizierungsstellen-Datenbank existiert.

certutil -view -restrict "SerialNumber=<Seriennummer>"

Dummy-Zertifikat erstellen

Im Katastrophenfall ist man in den meisten Fällen nicht mehr im Besitz der Zertifikate. Da die Sperrung eines Zertifikats erfordert, dass sich ein entsprechendes Zertifikat in der Zertifizierungsstellen-Datenbank befindet, muss zunächst ein Dummy-Zertifikat mit der entsprechenden Seriennummer erzeugt werden. Als "Signaturzertifikat" wählt man das der Zertifizierungsstelle aus.

certutil -sign "<Seriennummer>" <Dateiname>

Dummy-Zertifikat in die Zertifizierungsstellen-Datenbank importieren

Das erstellte Zertifikat kann nun in die Zertifizierungsstellen-Datenbank importiert werden.

certutil -importcert <Dateiname>

Sperren des Zertifikats

Anschließend kann es per Zertifizierungsstellen-Verwaltungskonsole oder Kommandozeile gesperrt werden.

certutil -revoke <Seriennummer> <Grundcode>

Die möglichen Codes für den Sperrungsgrund können nachfolgender Tabelle entnommen werden:

CodeBezeichnungBeschreibung
0UnspecifiedDies ist die Standardeinstellung und gibt an, dass es keinen speziellen Grund für den Widerruf gibt.
1Key CompromiseDer private Schlüssel eines Zertifikats wurde entwendet oder anderweitig unbefugten Dritten bekannt.
2CA CompromiseDer private Schlüssel der Zertifizierungsstelle wurde entwendet oder anderweitig unbefugten Dritten bekannt.
3Affiliation ChangedWenn sich der Inhalt des Zertifikats (z.B. der Name des Benutzers) geändert hat, muss ein neues Zertifikat ausgestellt werden.
4SupersededDas widerrufene Zertifikat wurde durch ein neues Zertifikat ersetzt.
5Cessation of OperationDer Betrieb des zum Zertifikate gehörenden Dienstes wurde eingestellt, etwa weil es einen neuen Dienst unter anderem Namen gibt.
6Certificate HoldDas Zertifikat wird vorübergebend widerrufen. Dieser Sperrungstyp ist der einzige, bei dem die Sperrung nachträglich wieder rückgängig gemacht werden kann.
8Remove from CRLWurde ein Zertifikat mit Grund "Certificate Hold" widerrufen und werden Deltasperrlisten verwendet, wird das entsperrte Zertifikat mit diesem Code in der Deltasperrliste geführt bis der Eintrag in der Haupt-Sperrliste entfällt.
-1UnrevokeWurde ein Zertifikat mit Grund "Certificate Hold" widerrufen, kann mit diesem Code eine Entsperrung per Kommandozeile erfolgen. Ebenso wird im Audit-Ereignis 4870 die Rückgängigmachung einer Zertifikatsperrung mit diesem Code kenntlich gemacht.

Neue Sperrliste veröffentlichen

Damit die Sperrung effektiv wird, muss noch eine neue Sperrliste veröffentlicht werden.

certutil -crl

Siehe hierzu auch Artikel "Erstellen und Veröffentlichen einer Zertifikatsperrliste".

Bitte beachten, dass bis zum Ablaufzeitpunt der vorigen Sperrliste nicht garantiert werden kann, dass die PKI-Teilnehmer die Sperrung als solche erkennen, da (zumindeste im Windows-Ökosystem) Sperrlisten in einem clientseitigen Zwischenspeicher (Cache) vorgehalten werden. Das gleiche gilt auch für Antworten des Onlineresponders (OCSP).

Fehler bei Verwendung von Windows Server 2008 R2

Auf Windows Server 2008 R2 kann es zu folgendem Fehler kommen:

CertUtil: -CRL command FAILED: 0xc0000005 (-1073741819)
CertUtil: The instruction at 0x%081x referenced memory at 0x%081x. The memory could not be %s.

In diesem Fall hilft es, diesen Hotfix zu installieren.

Kann ich auf diese Weise auch Zertifikate sperren, wenn meine Zertifizierungsstelle kompromittiert wurde?

Ausgelöst durch die Arbeit von Will Schroeder und Lee Christensen im Sommer 2021 haben sich Diskussionen entwickelt, dass auf diese Weise auch Zertifikate, die unter Umgehung der Zertifizierungsstelle signiert wurden, gesperrt werden könnten.

Prinzipiell und rein technisch betrachtet ist dies korrekt, löst aber das eigentliche Problem nicht. Wenn jemand in der Lage ist, Zertifikate mit dem privaten Schlüssel der Zertifizierungsstelle zu signieren, hilft eine einzelne Zertifikatsperrung recht wenig, da weiterhin die Kontrolle über den privaten Schlüssel der Zertifizierungsstelle verloren ist.

Bei Kompromittierung des privaten Schlüssels eine Zertifizierungsstelle ist meiner Meinung nach einzige Möglichkeit, zu einem "sicheren" Betrieb zurückzukehren, eine schnellstmögliche Außerbetriebnahme der betroffenen Zertifizierungsstelle unter Entzug des Vertrauensstatus (mindestens Sperrung des Zertifizierungsstellen-Zertifikats) und ein kompletter Neuaufbau.

Dass die zugrundeliegenden Angriffsvektoren zuvor abgestellt worden sein müssen versteht sich hierbei von selbst.

Weiterführende Links:

Externe Quellen