certutil – Seite 2 – Uwe Gradenegger

Es wird kein Zertifikat per Autoenrollment beantragt, wenn ein Benutzer per Virtual Private Network (VPN) verbunden ist

Folgendes Szenario angenommen:

Ein Benutzer arbeitet remote über Virtual Private Network (VPN)
Eigentlich sollte per Autoenrollment ein Zertifikat beantragt werden, dies erfolgt jedoch nicht
Ein Verbindungstest (certutil -ping) zur Zertifizierungsstelle wirft folgende Fehlermeldung:

Server could not be reached: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE) -- (31ms)

CertUtil: -ping command FAILED: 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
CertUtil: The RPC server is unavailable.

Der Widerruf eines ausgestellten Zertifikats schlägt fehl mit Fehlermeldung "The data is invalid. 0x8007000d (WIN32: 13 ERROR_INVALID_DATA)"

Folgendes Szenario angenommen:

Es wird ein Zertifikat über die Kommandozeile widerrufen (certutil -revoke).
Der Vorgang schlägt mit folgender Fehlermeldung fehl:

ICertAdmin::RevokeCertificate: The data is invalid. 0x8007000d (WIN32: 13 ERROR_INVALID_DATA)

Microsoft Outlook: Empfänger-Zertifikate bei S/MIME verschlüsselten Mails herausfinden

Zur Fehlersuche bei mittels Secure/Multipurpose Internet Mail Extensions (S/MIME) verschlüsselten E-Mail Nachrichten, kann der verschlüsselte Teil einer Nachricht exportiert werden. Siehe hierzu Artikel "Microsoft Outlook: Extrahieren einer verschlüsselten S/MIME Nachricht aus einer E-Mail".

Um herauszufinden, mit welchen Zertifikaten eine Nachricht verschlüsselt wurde, kann wie folgt vorgegangen werden…

Microsoft Outlook: Einsehen, welcher Algorithmus für eine S/MIME verschlüsselte oder signierte E-Mail verwendet wurde

Nachfolgend wird beschrieben, an welcher Stelle eingesehen werden kann, welcher symmetrische Algorihmus für die Verschlüsselung einer erhaltenen E-Mail verwendet wurde, und welcher Hashalgoritmus für eine signierte E-Mail verwendet wurde.

Die erweiterte Schlüsselverwendung (Extended Key Usage, EKU) für importierte Stammzertifizierungstellen-Zertifikate einschränken

Eine sinnvolle Härtungsmaßnahme für Zertifizierungsstellen ist das Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten erweiterten Schlüsselverwendungen (Extended Key Usage) vertraut wird.

Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann auf diese Extended Key Usages beschränkt. Das Smart Card Logon Extended Key Usage wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Windows Defender erkennt certutil als Schadsoftware (Win32/Ceprolad.A)

Folgendes Szenario angenommen:

Man führt einen Funktionstest für den Zertifizierungsstellen-Richtlinienserver (Certificate Enrollment Policy Web Server, CEP) durch.
Hierfür verwendet man einen certutil-Befehl, der die Kerberos-Authentifizierung verwendet, z.B.:

certutil -ping -kerberos -config "https://{Servername}/ADPolicyProvider_CEP_Kerberos/service.svc/CEP" CEP

Der certutil Befehl wird vom Windows Defender bzw. Windows Defenter Advanced Threat Protection fälschlicherweise als Win32/Ceprolad.A erkannt.

Konfiguration der Überwachung von Sicherheitsereignissen (Auditierungseinstellungen) für Zertifizierungsstellen

Im Gegensatz zu betrieblichen Ereignissen, die oft unter dem Begriff "Monitoring" verstanden werden, handelt es sich bei der Auditierung für die Zertifizierungsstelle um die Konfiguration der Protokollierung von sicherheitsrelevanten Ereignissen.

Funktionstest durchführen für eine Zertifizierungsstelle

Nach der Installation einer Zertifizierungsstelle, nach der Migration auf einen neuen Server, oder nach umfangreicheren Wartungsarbeiten sollte ein ausgiebiger Funktionstest erfolgen, um sicherzustellen, dass alle Komponenten der Zertifizierungsstelle wie gewünscht arbeiten.

Veröffentlichen einer Zertifikatsperrliste (CRL) auf einem Active Directory Sperrlistenverteilungspunkt (CDP)

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.

In manchen Fällen (beispielsweise bei einer Offline-Zertifizierungsstelle, oder wenn vom Standard abweichende LDAP-Sperrlistenverteilungspunkte konfiguriert wurden) muss die Zertifikatsperrliste manuell ins Active Directory veröffentlicht werden.

Erstellen und Veröffentlichen einer Zertifikatsperrliste

Nachdem ein Zertifikat widerrufen wurde, muss eine neue Sperrliste erstellt und veröffentlicht werden, damit Entitäten, die den Sperrstatus überprüfen, über die Sperrung informiert werden. Da die Sperrliste ein verhältnismäßig kurzes Ablaufdatum hat, muss sie auch ohne inhaltliche Änderung in regelmäßigen Abständen neu ausgestellt werden.

Widerrufen eines ausgestellten Zertifikats

Beim Widerrufen eines Zertifikats wird dessen Seriennummer auf die Sperrliste gesetzt. Entitäten, die die Sperrung eines Zertifikats überprüfen, betrachten es dann als nicht mehr gültig.

Nach Installation oder Migration einer Zertifizierungsstelle auf einen neuen Server können keine eigenen Zertifikatvorlagen mehr veröffentlicht werden

Folgendes Szenario angenommen:

Es ist eine Active Directory integrierte Zertifizierungsstelle (Enterprise CA) im Netzwerk integriert.
Die Zertifizierungsstelle wurde auf einen neuen Server migriert (siehe auch Artikel "Migration einer Active Directory integrierten Zertifizierungsstelle (Enterprise Certification Authority) auf einen anderen Server").
Beim Veröffentlichen der Zertifikatvorlagen stellt man fest, dass sich nur die Standard-Zertifikatvorlagen zur Veröffentlichung auswählen lassen. Eigene Zertifikatvorlagen werden nicht angezeigt.

Manuelles Ausführen des Autoenrollment Prozesses

In der Standardeinstellung replizieren alle Domänenmitglieder durch den Autoenrollment Prozess automatisch das Public Key Services Objekt er Active Directory Gesamtstruktur. Die Auslöser hierfür sind:

Bei Anmeldung des Benutzers (bei Computern, wenn sich das Computerkonto anmeldet, also beim Systemstart)
Per Timer alle 8 Stunden.
Bei einer Aktualisierung der Gruppenrichtlinien, vorausgesetzt, es gab eine Änderung.

Möchte man nicht darauf warten, bis der Autoenrollment automatisch angestoßen wird, kann man ihn auch manuell starten. Die verschiedenen Wege, den Autoenrollment Prozess auszuführen, werden nachfolgend beschrieben.

Eine Zertifikatanforderung (CSR) inspizieren

Oft möchte man eine Zertifikatanforderung vor der Übermittlung an eine Zertifizierungsstelle – oder vor der Ausstellung des Zertifikats – überprüfen, ob sie die gewünschten Werte beinhaltet.

Nachfolgend wird beschrieben, wie man dies erreichen kann.

Den Subject Distinguished Name (DN) einer Zertifikatanforderung (CSR) nachträglich verändern

Manchmal ist es erforderlich, dass der Subject Distinguished Name (auch Subject, Subject DN, Antragsteller oder Betreff genannt) einer Zertifikatanforderung vor Ausstellung des Zertifikats verändert wird.

Unter bestimmten Umständen ist dies durchaus möglich, wie nachfolgend beschrieben wird.