Internet-Informationsdienste (IIS)

Liste der Use Cases der Zertifikate, für welche die Kompatibilität zu auf elliptischen Kurven (ECC) basierenden Schlüsseln bekannt ist

Mit zunehmend zur Verfügung stehender Rechenleistung steigt auch der Bedarf, stärkere kryptographischer Schlüssel einzusetzen. Oftmals besteht der Bedarf (beispielsweise, weil die Schlüssel per Trusted Platform Modul geschützt werden müssen), in diesem Zug auf elliptischen Kurven (ECC) basierende Schlüssel einzusetzen. Für deren Einsatz ist es essenziell, dass die Kompatibilität zu den vorgesehenen Use Cases sichergestellt ist.

Nachfolgend eine Liste von Use Cases, für welche mir die Kompatibilität bekannt ist.

Grundlagen: Authentisierungsverfahren für die Internet Information Services (IIS)

Die Active Directory Certificate Services bieten eine Reihe von webbassierten Zusatz-Schnittstellen (Registrierungsdienst für Netzwerkgeräte (NDES), Zertifikatregistrierungs-Richtliniendienst (CEP), Zertifikatregistrierungs-Webdienst (CES), Zertifizierungsstellen-Webregistrierung (CAWE).

Die Microsoft Internet Information Services (IIS) sind also für eine Microsoft-PKI nahezu unentbehrlich. Jede der webbasierten Schnittstellen (und auch Eigenentwicklungen) bringen ihre ganz eigenen Herausforderungen in Hinsicht auf Authentisierungsverfahren und deren Implementierung.

Nachfolgender Beitrag soll ein wenig Klarheit in das Thema bringen.

Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

Verwenden von Microsoft Network Load Balancing (NLB) für die Zertifikatregistrierungs-Webdienste (CEP, CES)

Es ist allgemein eine gute Idee, die Verfügbarkeit der Zertifikatregistrierungs-Webdienste (Zertifikatregistrierungs-Richtliniendienst, CEP und Zertifikatregistrierungs-Webdienst, CES) jederzeit sicherzustellen.

Nachfolgend wird beschrieben, wie dies mit dem Windows-Feature "Network Load Balancing" (NLB) erreicht werden kann.

Den Certificate Enrollment Web Service (CES) für den Betrieb mit einem Group Managed Service Account (gMSA) konfigurieren

Aus Sicherheitsgründen kann es sinnvoll sein, den CES statt mit einem normalen Domänenkonto lieber mit einem Group Managed Service Account (gMSA) zu betreiben. Diese Option bietet den charmanten Vorteil, dass das Passwort des Kontos automatisch geändert wird, und dieser Schritt somit nicht von Hand vorgenommen werden muss, was leider viel zu oft vergessen wird.

Secure Sockets Layer (SSL) für die Zertifizierungsstellen-Webregistrierung (CAWE) aktivieren

In der Standardkonfiguration nimmt die Zertifizierungsstellen-Webregistrierung (Certificate Authority Web Enrollment CAWE) nur unverschlüsselte Verbindungen via HTTP an. Es ist angeraten, dass die CAWE für HTTP über TLS (HTTPS) konfiguriert wird, um Mitschnitte des Netzwerkverkehrs zu erschweren. Nachfolgend eine Anleitung.

Installation eines Certificate Enrollment Policy Web Service (CEP)

Nachfolgend wird beschrieben, wie der Certificate Enrollment Policy Web Service (CEP) installiert werden kann.

Den Certificate Enrollment Policy Web Service (CEP) für den Betrieb mit einem Domänenkonto konfigurieren

Nachfolgend wird beschrieben, wie man einen Certificate Enrollment Policy Web Service (CEP) einrichtet, dass der Dienst unter einem Domänenkonto läuft.

Den Certificate Enrollment Policy Web Service (CEP) für den Betrieb mit einem Group Managed Service Account (gMSA) konfigurieren

Aus Sicherheitsgründen kann es sinnvoll sein, den CEP statt mit einem normalen Domänenkonto lieber mit einem Group Managed Service Account (gMSA) zu betreiben. Diese Option bietet den charmanten Vorteil, dass das Passwort des Kontos automatisch geändert wird, und dieser Schritt somit nicht von Hand vorgenommen werden muss, was leider viel zu oft vergessen wird.

Die Network Device Enrollment Service (NDES) Administrations-Webseite (certsrv/mscep_admin) meldet "You do not have sufficient permission to enroll with SCEP. Please contact your system administrator."

Folgendes Szenario angenommen:

Ein NDES Server ist im Netzwerk konfiguriert.
Bei Aufruf der Administrations-Webseite (certsrv/mscep_admin) kommt folgende Meldung:

You do not have sufficient permission to enroll with SCEP. Please contact your system administrator.

Die Rollenkonfiguration für den Registrierungsdienst für Netzwerkgeräte (NDES) schlägt fehl mit Fehlermeldung "CMSCEPSetup::Install: The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)"

Folgendes Szenario angenommen:

Man installiert einen Network Device Enrollment Service (NDES) Server.
Die Rollenkonfiguration schlägt mit folgender Fehlermeldung fehl:

CMSCEPSetup::Install: The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)

Secure Sockets Layer (SSL) für den Registrierungsdienst für Netzwerkgeräte (NDES) aktivieren

In der Standardkonfiguration nimmt der Network Device Enrollment Service (NDES) nur unverschlüsselte Verbindungen via HTTP an. Es ist angeraten, dass zumindest die Administrations-Webseite von NDES für HTTP über TLS (HTTPS) konfiguriert wird, um Mitschnitte des Netzwerkverkehrs zu erschweren. Nachfolgend eine Anleitung.

Für eine nähere Betrachtung zur Notwendigkeit der Verwendung von SSL siehe Artikel "Sollte HTTPS für den Registrierungsdienst für Netzwerkgeräte (NDES) verwendet werden?".

Verwenden von Microsoft Network Load Balancing (NLB) für die Sperrlistenverteilungspunkte (CDP), den Zugriff auf Stelleninformationen (AIA) und Onlineresponder (OCSP)

Es ist allgemein eine gute Idee, die Verfügbarkeit der Sperrlistenverteilpunkte (CRL Distribution Point, CDP), der Stelleninformationen (Authority Information Access, AIA) und falls vorhanden der Online Responder (OCSP) jederzeit sicherzustellen.

Der Zugriff auf die Revokierungs-Informationen ist sogar kritischer als auf die Zertifizierunsstelle selbst. Kann der Sperrstatus eines Zertifikats nicht geprüft werden, kann es (je nach Anwendung) sein, dass das Zertifikat nicht als vertrauenswürdig erachet wird, und der dazugehörige IT-Dienst nicht benutzt werden kann.

Übertragen der Zertifikatsperrlisten auf die Sperrlistenverteilpunkte mit SSH Secure Copy (SCP) mit Authentifizierung über öffentliche Schlüssel (Windows Server 2019)

Wenn sich die Server, welche die Sperrlistenverteilpunkte bereitstellen, beispielsweise in einer Demilitarisierten Zone (DMZ) befinden, oder aus anderen Gründen kein Datentransfer via Server Message Block (SMB) möglich ist, können die Sperrlisten mittels SSH Secure Copy (SCP) auf die Verteilpunkte übertragen werden. Seit Windows Server 2019 gibt es die OpenSSH Server und Client-Pakete. Nachfolgend wird die Einrichtung mit Authentifizierung über öffentliche Schlüssel (Public Key Authentication) anstelle von Passwörtern exemplarisch beschrieben