Uwe Gradenegger – Seite 41 – Uwe Gradenegger

Konfigurieren der Zertifizierungsstelle auf einen statischen Port (RPC-Endpunkt)

In der Standardkonfiguration ist die Zertifikatbeantragungs-Schnittstelle der Zertifizierungsstelle darauf konfiguriert, dynamische Ports für die eingehenden RPC/DCOM Verbindungen auszuhandeln (näheres siehe Artikel "Benötigte Firewallregeln für Active Directory Certificate Services").

Netzwerkprotokoll	Ziel-Port	Protokoll
TCP	135	RPC Endpoint Mapper
TCP	49152-65535	RPC dynamische Ports

Diese Konfiguration ist nicht in jeder Unternehmens-Umgebung realisierbar. Oftmals gibt es restriktive Firewallregeln, welche die Verwendung dynamischer Netzwerk-Ports nicht erlauben.

In einem solchen Fall muss die Zertifizierungsstelle auf einen statischen Port konfiguriert werden.

Abfrage der konfigurierten RPC-Endpunkte einer Zertifizierungsstelle

In der Standardkonfiguration ist die Zertifikatbeantragungs-Schnittstelle der Zertifizierungsstelle darauf konfiguriert, dynamische Ports für die eingehenden RPC/DCOM Verbindungen auszuhandeln (näheres siehe Artikel "Benötigte Firewallregeln für Active Directory Certificate Services").

Es ist jedoch auch möglich, die Zertifizierungsstelle auf einen statischen Port zu konfigurieren (siehe Artikel "Konfigurieren der Zertifizierungsstelle auf einen statischen Port (RPC-Endpunkt)").

Nachfolgend wird beschrieben, wie die aktuelle Konfiguration der Zertifizierungsstelle überprüft werden kann.

Einordnung der ADCS-Komponenten in das administrative Schichtenmodell (Administrative Tiering Model)

Implementiert man neben den Active Directory Certificate Services auch das administrative Schichtenmodell (Administrative Tiering Model) für den Active Directory Verzeichnisdienst, stellt sich die Frage der Zuordnung der einzelnen PKI-Komponenten in dieses Modell, um eine zielgerichtete Sicherheitshärtung vornehmen zu können.

Manuelles Zuweisen eines Remotedesktop (RDP) Zertifikats

Wurde ein Remotedesktop-Zertifikat manuell beantragt, muss es dem Remotedesktop-Sitzungshost anschließend noch zugewiesen werden.

Manuelle Beantragung eines Remotedesktop (RDP) Zertifikats

Es gibt Fälle, in welchen man Remotedesktop-Zertifikate nicht von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte, beispielsweise wenn das betreffende System kein Domänenmitglied ist.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).

Die Erstellung einer manuellen Zertifikatanforderung schlägt fehl mit Fehlermeldung "Expected INF file section name 0xe0000000"

Folgendes Szenario angenommen:

Es wird eine Informationsdatei für eine manuelle Zertifikatanforderung erstellt.
Die Erstellung der Zertifikatanforderung unter Verwendung der Datei schlägt mit folgender Fehlermeldung fehl:

Expected INF file section name 0xe0000000 (INF: -536870912)

Eine manuell erstellte Zertifikatanforderung an eine Zertifizierungsstelle senden

Liegt eine Zertifikatanforderung, beispielsweise nach manueller Erzeugung, in Form einer Textdatei (üblicherweise mit Endung .CSR oder .REQ) vor, kann diese mit Bordmitteln an die Zertifizierungsstelle gesendet werden.

Die Beantragung eines Zertifikats über den Certificate Enrollment Web Service (CES) schlägt fehl mit dem Fehlercode "WS_E_ENDPOINT_FAULT_RECEIVED"

Folgendes Szenario angenommen:

Es ist ein Certificate Enrollment Web Service (CES) im Netzwerk implementiert.
Es wird eine Zertifikatanforderung an den CES gesendet.
Die Beantragung des Zertifikats schlägt mit folgender Fehlermeldung fehl:

A message containing a fault was received from the remote endpoint. 0x803d0013 (-2143485933 WS_E_ENDPOINT_FAULT_RECEIVED)

Chrome und Safari limitieren SSL Zertifikate auf ein Jahr Gültigkeit

Apple hat vor kurzem angekündigt, dass der Safari-Browser künftig nur noch Zertifikate mit einer Gültigkeit von 398 Tagen akzeptieren wird, sofern diese ab 1. September 2020 ausgestellt wurden.

Mozilla und Google wollen in ihren Browsern ein vergleichbares Verhalten implementieren. Es stellt sich also die Frage, ob diese Änderung Auswirkungen auf interne Zertifizierungsstellen haben wird – ob künftig also auch interne SSL-Zertifikate diese Regeln befolgen müssen, wie es beispielsweise bei der Erzwingung des RFC 2818 durch Google der Fall war.

Literatur und weitere Ressourcen über Public Key Infrastrukturen und Active Directory Certificate Services

Nachfolgend eine Übersicht über am Markt erhältliche Literatur zum Thema Public Key Infrastrukturen und Active Directory Certificate Services sowie Online-Ressourcen von Microsoft und anderen PKI Spezialisten.

Performanceprobleme bei Auditierung von "Start and stop Active Directory Certificate Services"

Bei der Konfiguration der Auditierungseinstellungen einer Zertifizierungsstelle ist man geneigt, die Option "Start and Stop Active Directory Certificate Services" auszuwählen. Diese Option kann unter Umständen jedoch zu Problemen führen.

Mehr als ein gemeinsamer Name (Common Name, CN) im Zertifikat

Heutzutage eher eine Kuriosität als wirklich praxisrelevant, aber es kommt hin und wieder vor, dass man Zertifikatanforderungen erhält, welche mehr als einen gemeinsamen Namen (Common Name) im Betreff (Subject) beinhalten. Auch wenn es erstaunlich wirken mag, dies ist durchaus möglich und auch RFC-konform.

Das SMTP Exit Modul funktioniert nicht auf Windows Server Core

Folgendes Szenario angenommen:

Es wird eine Zertifizierungsstelle auf Windows Server Core installiert.
Es wird das mit der Zertifizierungsstelle mitgelieferte SMTP Exit Modul konfiguriert.
Die Zertifizierungsstelle versendet jedoch keine E-Mails.
Im Ereignisprotokoll wird das Ereignis Nr. 46 mit folgender Fehlermeldung protokolliert:

The "Windows default" Exit Module "Initialize" method returned an error. Class not registered The returned status code is 0x80040154 (-2147221164). The Certification Authority was unable to initialize email messaging objects.

Die Beantragung eines bestimmten Signaturschlüssels auf einer Zertifizierungsstelle erlauben

Die Microsoft-Zertifizierungsstelle signiert Zertifikate immer mit dem zum aktuellsten Zertifizierungsstellen-Zertifikat gehörenden Schlüssel. Das Signaturzertifikat für eine OCSP-Antwort sollte gemäß RFC 6960 jedoch vom gleichen Schlüssel signiert werden, wie das zu überprüfende Zertifikat:

The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation.
https://tools.ietf.org/html/rfc6960#section-4.2.2.2

Wird das Zertifizierungsstellen-Zertifikat erneuert und dabei ein neues Schlüsselpaar verwendet, ist es jedoch erforderlich, dass der Onlineresponder weiterhin gültige Signaturzertifikate für die mit dem vorigen Zertifizierungsstellen-Zertifikat ausgestellten Zertifikate vorhält, da diese schließlich weiterhin gültig sind und auf Sperrung überprüft werden müssen.

Die Beantragung eines Zertifikats schlägt fehl mit Fehlermeldung "The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)"

Folgendes Szenario angenommen:

Es wird eine Zertifikatanforderung an eine Zertifizierungsstelle gesendet.
Die Beantragung des Zertifikats schlägt mit folgender Fehlermeldung fehl:

Error Parsing Request The system cannot find the file specified. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)

Deutsch