certutil – Uwe Gradenegger

Nachträgliche Archivierung privater Schlüssel

Für die Veschlüsselung von E-Mail Nachrichten verwenden Unternehmen üblicherweise den Secure / Multipurpose Internet Message Extensions (S/MIME) Standard und stellen ihren Benutzern hierfür entsprechende Zertifikate zur Verfügung.

Ein wichtiger Aspekt hierbei ist, dass die privaten Schlüssel der Benutzer – im Gegensatz zu den ansonsten meist verwendeten Signaturzertifikaten – zentral gesichert werden sollten. Eingehende Nachrichten sind für einen bestimmten privaten Schlüssel verschlüsselt und können nur von diesem auch wieder entschlüsselt werden. Somit muss unbedingt eine Sicherung dieser Schlüssel vorliegen – auch für die Synchronisierung auf mobile Endgeräte ist dies unabdingbar. Hierfür bieten die Microsoft Active Directory Certificate Services die Funktion der Archivierung privater Schlüssel (engl. Private Key Archival).

Was aber, wenn die Archivierung der privaten Schlüssel nicht eingerichtet wurde, und Benutzer bereits entsprechende Zertifikate beantragt haben?

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

Zeichenkodierung im Subject Distinguished Name von Zertifikatanforderungen und ausgestellten Zertifikaten

Üblicherweise ist die Kodierung von Zeichen und Zeichenketten in Zertifikaten kein Thema, welches die Nutzer einer PKI groß interessiert. Es gibt jedoch Fälle, in welchen die Standardeinstellungen der Zertifizierungsstelle nicht die gewünschten Ergebnisse liefern.

Die Partition des Hardware Security Moduls (HSM) läuft voll

Folgendes Szenario angenommen:

Eine Zertifizierungsstelle verwendet ein Hardware Security Modul (HSM).
Die Partition des Hardware Security Moduls füllt sich über die Lebenszeit der Zertifizierungsstelle mit immer mehr Schlüsseln.
Bei SafeNet Hardware Security Modulen kann dies sogar dazu führen, dass die Partition voll läuft. In Folge dessen werden die Ereignisse 86 und 88 der Zertifizierungsstelle protokolliert.

Die Überprüfung der Domänencontroller-Zertifikate wirft den Fehlercode ERROR_ACCESS_DENIED

Folgendes Szenario angenommen:

Mit certutil wird eine Überprüfung der Domänencontroller-Zertifikate durchgeführt.
Der Vorgang schlägt mit folgender Fehlermeldung fehl:

0: DC01

*** Testing DC[0]: DC01
Enterprise Root store: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)
KDC certificates: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)

CertUtil: -DCInfo command FAILED: 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)
CertUtil: Access is denied.

Was passiert, wenn ein Benutzer mehrere Zertifikate beantragt hat?

Ich bin neulich auf das Phänomen getroffen, dass aufgrund einer fehlerhaften Beantragungslogik mehrere Benutzer in regelmäßigen Anständen neue Zertifikatanforderungen gestellt hatten.

Die Zertifikatvorlage war konfiguriert, eingehende Zertifikatanforderungen durch einen Zertifikatmanager freigeben zu lassen, d.h. es erfolgte keine automatische Ausstellung der Zertifkate. Die Zertifikatanforderungen sollten durch einen eigenen Code überprüft und anschließend freigegeben werden.

Man würde nun erwarten, dass (da alle Zertifikatanträge letztendlich genehmigt würden) die Benutzer nun mehrere Zertifikate gleichen Typs in ihrem Zertifikatspeicher (und den Anwendungen, welche diesen nutzen) vorfinden würden. Dem war aber nicht der Fall.

Das Datenbankschema der Zertifizierungsstellen-Datenbank

Möchte man Abfragen gegen die Zertifizierungsstellen-Datenbank formulieren, muss man zuerst wissen, wonach man suchen möchte.

Es gibt die Möglichkeit, das Datenbankschema der Zertifizierungsstellen-Datenbank ausgeben zu lassen.

Die Wiederherstellung der Verbindung zum privaten Schlüssel schlägt fehl mit Fehlermeldung "Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Folgendes Szenario angenommen:

Eine Zertifizierungsstelle wird auf einen anderen Server migriert oder aus der Sicherung wiederhergestellt.
Zum Schutz des privaten Schlüssels des Zertifizierungsstellen-Zertifikats kommt ein Hardware Security Modul (HSM) zum Einsatz.
Das Zertifizierungsstellen-Zertifikat soll nun auf dem Zielsystem wiederhergestellt und mit dem privaten Schlüssel verbunden werden.
Der Vorgang schlägt mit folgender Fehlermeldung fehl:

Cannot find the certificate and private key for decryption.
CertUtil: -repairstore command FAILED: 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
CertUtil: Cannot find object or property.

Die Installation der Standard-Zertifikatvorlagen schlägt fehl mit Fehlermeldung "This security ID may not be assigned as the owner of this object."

Folgendes Szenario angenommen:

Es soll erstmalig eine ins Active Directory integrierte Zertifizierungsstelle (Enterprise Certification Authority) im Netzwerk installiert werden.
Die Rechte für die Installation der Zertifizierungsstelle wurden aus Sicherheitsgründen auf eine separate Sicherheitsgruppe oder ein separates Konto delegiert, sodass keine Anmeldung als Enterprise Administrator erforderlich ist. Andersherum formuliert: Der verwendete Benutzer ist nicht Mitglied der Gruppe "Enterprise Administrators" in der Active Directory Gesamtstruktur.
Da es sich um die erste Zertifizierungsstelle im Netzwerk handelt, sind noch keine Standard-Zertifikatvorlagen im Active Directory installiert. Beim Öffnen der Verwaltungskonsole für Zertifikatvorlagen (certtmpl.msc) wird man aufgefordert, diese zu installieren.
Die Installation schlägt mit folgender Fehlermeldung fehl:

Windows could not install the new certificate templates. This security ID may not be assigned as the owner of this object.

Codesignaturen von Appx Paketen per SignTool.exe schlagen fehl mit Fehlercode 0x8007000b (ERROR_BAD_FORMAT)

Folgendes Szenario angenommen:

Es soll ein Appx Paket signiert werden.
Hierfür wird die SignTool.exe verwendet.
Das verwendete Codesignaturzertifikat wurde jüngst erneuert.
Der Signaturvorgang mit dem neuem Codesignaturzertifikat schlägt mit folgender Fehlermeldung fehl:

"Error: SignerSign() failed." (-2147024885/0x8007000b)

Zertifikate mit verkürzter Gültigkeitsdauer ausstellen

Manchmal ist es erforderlich, Zertifikate mit einer kürzeren Gültigkeitsdauer auszustellen, als sie in der Zertifikatvorlage konfiguriert ist. Vielleicht möchte man deshalb nicht gleich die Zertifikatvorlage umkonfigurieren oder eine weitere Zertifikatvorlage erstellen.

Stammstellen-Zertifikate werden auf Domänenmitgliedern in den Zertifikatspeicher für Zwischenzertifizierungsstellen importiert

Manch einem wird aufgefallen sein, dass der Zertifikatspeicher für Zwischenzertifizierungsstellen üblicherweise auch Zertifikate für Stammzertifizierungsstellen beinhaltet.

In der Regel ist dieses Verhalten unkritisch. In bestimmten Fällen kann dies allerdings auch Probleme mit Anwendungen hervorrufen.

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.

Der lokale Zertifikatspeicher für vertrauenswürdige Stammzertifizierungsstellen wird nicht aus dem Active Directory synchronisiert

Folgendes Szenarion angenommen:

Es ist eine Zertifizierungsstellen-Hierarchie im Netzwerk etabliert und die Stammzertifizierungsstelle ist in der Configuration-Partition der Active Directory Gesamtstruktur abgebildet.
Die Domänenmitglieder sind konfiguriert, den Autoenrollment-Prozess auszuführen und somit vertrauenswürdige Stammzertifizierungsstellen aus der Configuration-Partition zu aktualisieren.
Bei einigen Clients funktioniert dieser Prozess allerdings nicht. Die Stammzertifizierungsstellen-Zertifikate werden nicht automatisch heruntergeladen und in den lokalen Vertrauensspeicher eingetragen.
Als Folgeerscheinung können Zertifikatbeantragungen fehlschlagen, da beispielsweise der Zertifizierungsstellen-Hierarchie nicht vertraut wird.

Fehlersuche für die automatische Zertifikatbeantragung (Autoenrollment) via RPC/DCOM

Folgendes Szenario angenommen:

Es ist eine Zertifikatvorlage für die automatische Beantragung von Zertifikaten konfiguriert (Autoenrollment).
Die Zertifikatvorlage ist auf einer ins Active Directory integrierten Zertifizierungsstelle (Enterprise Certification Authority) veröffentlicht.
Die für die automatische Zertifikatbeantragung konfigurierten Benutzer oder Computer beantragen allerdings nicht wie vorgesehen Zertifikate.

Nachfolgend eine Anleitung zur Fehlersuche.

Deutsch