Uwe Gradenegger – Seite 38 – Uwe Gradenegger

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.

Deaktivieren der Erzeugung der Kreuzzertifizierungsstellen-Zertifikate auf einer Stammzertifizierungsstelle

Stammzertifizierungsstellen (Root CA) erzeugen bei Erneuerung des Zertifizierungsstellen-Zertifikats sogenannte Kreuzzertifizierungsstellen-Zertifikate (Cross Signing).

Mitunter kann es sein, dass hierbei Probleme auftreten, wie beispielsweise im Artikel "Die Beantragung eines Zertifizierungsstellen-Zertifikats schlägt fehl mit Fehlermeldung "The certification authority’s certificate contains invalid data. 0x80094005 (-2146877435 CERTSRV_E_INVALID_CA_CERTIFICATE)"" beschrieben.

In einem solchen Fall möchte man vielleicht die Erstellung der Kreuzzertifizierungsstellen-Zertifikate unterbinden.

Verwenden von HTTP über Transport Layer Security (HTTPS) für die Sperrlistenverteilungspunkte (CDP) und den Onlineresponder (OCSP)

In Hinsicht auf die Gestaltung der Infrastruktur zur Bereitstellung der Sperrinformationen – also der Sperrlistenverteilungspunkte (CRL Distribution Point, CSP) sowie der Online Responder (Online Certificate Status Protocol, OCSP) kommt die Frage auf, ob man diese über Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS) "absichern" sollte.

Umlaute in Zertifizierungsstellen-Zertifikaten

Internationalisierte Domänennamen (Internationalized Domain Names, IDNs) werden seit Windows Server 2012 im Rahmen der Zertifizierungsstelle und den dazugehörigen Komponenten offiziell unterstützt.

Möchte man diese in seine Zertifizierungsstellen-Zertifikaten benutzen, gibt es jedoch einige Besonderheiten zu beachten.

Welcher Cryptographic Service Provider (CSP) sollte für den Registrierungsdienst für Netzwerkgeräte (NDES) verwendet werden?

Bei der Konfiguration einer Zertifikatvorlage für die Registration Authority (RA) Zertifikate für den Registrierungsdienste für Netzwerkgeräte (Network Device Enrollment Service, NDES), kommt insbesondere bei der Verwendung von Hardware Security Modulen (HSM) die Frage auf, welcher Cryptographic Service Provider (CSP) des HSM-Herstellers verwendet werden sollte.

Die Beantragung von Zertifikaten über den Registrierungsdienst für Netzwerkgeräte (NDES) schlägt mit HTTP Fehlercode 503 fehl, und es gibt keine Einträge in der Ereignisanzeige

Folgendes Szenario angenommen:

Es ist ein Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) im Netzwerk implementiert.
Der NDES Server verwendet ein Domänenkonto oder einen Group Managed Service Account (gMSA) für die Identität des SCEP IIS-Anwendungspools.
Die Beantragung von Zertifikaten über NDES schlägt mit HTTP Fehlercode 503 (Server Unavailable) fehl.
Der Aufruf der mscep- und mscep_admin Seiten schlägt ebenfalls mit dem HTTP Fehlercode 500 fehl.
Auch nach einem iisreset bzw. Neustart des NDES Servers erscheint nach Aufruf der mscep oder mscsp_admin Seite kein Ereignis, dass der NDES Dienst gestartet wäre, oder dass es Fehler gegeben hätte.

Was ist bei der Anwendungen der Microsoft Security Baselines zu beachten?

Im Rahmen von Härtungsmaßnahmen bietet es sich an, die von Microsoft herausgegebenen Microsoft Security Baselines auf die eigene Serverlandschaft anzuwenden.

Dies wird zwangsläufig Auswirkungen auf die PKI-Komponenten haben. Nachfolgend eine Übersicht über die zu erwartenden Auswirkungen und Gegenmaßnahmen.

Der Zertifikatregistrierungs-Richtliniendienst zeigt Zertifikatvorlagen, die auf Kompatibilität mit Windows Server 2016 oder Windows 10 konfiguriert sind, nicht an

Es gibt einen bekannten Fehler im Zertifikatregistrierungs-Richtlinienwebdienst (Certificate Enrollment Policy Web Service, CEP), der dazu führt, dass Zertifikatvorlagen, die auf Kompatibilität mit Windows Server 2016 bzw. Windows 10 konfiguriert sind, nicht angezeigt werden.

Wie sind die Kompatibilitätseinstellungen für Zertifikatvorlagen technisch abgebildet?

Seit den Verwaltungstools für die Zertifikatdienste in Windows Server 2012 kann man beim Konfigurieren einer Zertifikatvorlage die gewünschte Kompatibilität für die Zertifizierungsstelle und Zertifikatempfänger auswählen.

Nachfolgend wird diese Funktion näher beschrieben, sowie auf mögliche Auswirkungen in der Praxis eingegangen.

Übersicht über die Verfügbarkeit von Optionen bei Veränderung der Kompatibilitätseinstellungen einer Zertifikatvorlage

Seit den Verwaltungstools für die Zertifikatdienste in Windows Server 2012 kann man beim Konfigurieren einer Zertifikatvorlage die gewünschte Kompatibilität für die Zertifizierungsstelle und Zertifikatempfänger auswählen.

Nachfolgend eine Übersicht, welche Optionen jeweils verfügbar werden, wenn die Kompatibilitätseinstellungen für die Zertifizierungsstelle und/oder die Zertifikatempfänger verändert werden.

Die Beantragung eines Zertifikats über die Zertifikatregistrierungs-Webdienste mittels Windows PowerShell schlägt fehlt mit Fehlermeldung "Access was denied by the remote endpoint. 0x803d0005 (-2143485947 WS_E_ENDPOINT_ACCESS_DENIED)"

Folgendes Szenario angenommen:

Es wird versucht, ein Zertifikat via Windows PowerShell über die Zertifikatbeantragungs-Richtliniendienste (Certificate Enrollment Web Services) zu beantragen.
Die Beantragung schlägt mit folgender Fehlermeldung fehl:

Get-Certificate : CX509EnrollmentPolicyWebService::LoadPolicy: Access was denied by the remote endpoint. 0x803d0005 (-2143485947 WS_E_ENDPOINT_ACCESS_DENIED)

Die Beantragung eines Zertifikats über die Zertifikatregistrierungs-Webdienste mittels Windows PowerShell schlägt fehlt mit Fehlermeldung "Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)"

Folgendes Szenario angenommen:

Es wird versucht, ein Zertifikat via Windows PowerShell über die Zertifikatbeantragungs-Richtliniendienste (Certificate Enrollment Web Services) zu beantragen. Der Name der Zertifikatvorlage wird mit dem -Template Argument mit angegeben.
Die Beantragung schlägt mit folgender Fehlermeldung fehl:

Get-Certificate : CertEnroll::CX509CertificateTemplates::get_ItemByName: Cannot find object or property. 0x80092004

(-2146885628 CRYPT_E_NOT_FOUND)

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.

Benötigte Windows-Sicherheitsberechtigungen für den Certificate Enrollment Policy Web Service (CEP)

Angenommen, man implementiert das Active Directory-Verwaltungsebenenmodell (Administrative Tiering Model) von Microsoft, oder wendet vergleichbare Härtungsmaßnahmen auf seinen Servern an, hat dies Auswirkungen auf die CEP Komponenten.

Automatisches Ändern der Passwörter für Konten, die eine Anmeldung via Smartcard oder Windows Hello for Business erfordern

Eine neue Funktion von Windows Server 2016 ist, dass die Passwörter für Konten, die eine reine Anmeldung mit Smartcards erfordern, gemäß den Passwortlichtlinien automatisch erneuert werden.

Wird die Option "Smart card is required for interactive logon" für ein Benutzerkonto aktiviert, wird das Kennwort des Benutzerkontos einmalig auf einen zufälligen Wert gesetzt. Das Passwort ändert sich jedoch anschließend nie mehr, was das Konto anfälliger für Pass-the-Hash Angriffe macht.

Die neu eingeführte Funktion löst dieses Problem, indem für entsprechende Konten regelmäßig (in Abhängigkeit der für das Konto konfigurierten Passwortrichtlinie) neue zufallsgenerierte Passwörter erzeugt werden.

Deutsch