RFC 5280 – Uwe Gradenegger

Wie viele Alternative Antragstellernamen (engl. Subject Alternative Name, SAN) unterstützen die Active Directory Certificate Services?

Wie jede Software unterliegen auch die Microsoft Active Directory Certificate Services bestimmten Grenzen, die durch ihr Design auferlegt sind.

Nicht so offensichtlich kann die Frage beantwortet werden, wie viele Alternative Antragstellernamen (engl. Subject Alternative Name, SAN) mit der Microsoft-Zertifizierungsstelle ausgestellt werden können.

Das IETF RFC 5280 beschreibt die Struktur für Subject Alternative Names wie folgt:

SubjectAltName ::= GeneralNames

Grundlagen: Namenseinschränkungen (Name Constraints)

Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.

Grundlagen: Die Key Usage Zertifikaterweiterung

Zertifikaterweiterungen wurden mit der Version 3 des X.509 Standards eingeführt. Die Key Usage Erweiterung ist eine optionale Zertifikaterweiterung, die im RFC 5280 definiert ist und dazu dient, die erlaubten Verwendungszwecke für einen Schlüssel zu begrenzen.

Die "Application Policies" Zertifikaterweiterung

Für welche Zwecke ein digitales Zertifikat verwendet werden darf, wird über die Zertifikaterweiterungen "Key Usage" und "Extended Key Usage" gesteuert.

In der "Extended Key Usage" Zertifikaterweiterung werden die erweiterten Schlüsselverwendungen eingetragen, für welche das Zertifikat verwendet werden darf.

Es gibt jedoch bei von einer Microsoft Zertifizierungsstelle ausgestellten Zertifikaten noch eine weitere Zertifikaterweiterung namens "Anwendungsrichtlinien" (engl. "Application Policies"), die ebenfalls eine der Extended Key Usages Erweiterung sehr ähnliche Liste enthält.

Grundlagen: Konfigurationsdatei für die Zertifizierungsstelle (capolicy.inf)

Die capolicy.inf beinhaltet grundlegende Einstellungen, die vor der Installation einer Zertifizierungsstelle festgelegt werden können oder sollten. Vereinfacht ausgedrückt kann man sagen, dass keine Zertifizierungsstelle ohne sie installiert werden sollte.

Grundlagen: Einschränkung der Pfadlänge (Path Length Constraint)

Der Ende 2008 vorgeführte Angriff auf den MD5 Signaturalgorithmus konnte nur deshalb zur Erstellung eines nutzbaren gefälschten Zertifizierungsstellen-Zertifikats verwendet werden, da die angegriffene Zertifizierungsstelle keine Einschränkung der Pfadlänge konfiguriert hatte.

Die Einschränkung der Pfadlänge ist im RFC 5280 beschrieben. Die Idee dahinter ist, dass in der "Basic Constraints" Erweiterung eines Zertifizierungsstellen-Zertifikats die maximale Tiefe der Zertifizierungsstellen-Hierarchie hinterlegt wird.

Grundlagen: Überprüfung des Sperrstatus von Zertifikaten

Soll ein gültiges, noch nicht abgelaufenes Zertifikat aus dem Verkehr gezogen werden, muss es widerrufen werden. Hierfür pflegen die Zertifizierungsstellen entsprechende Sperrlisten, in welchen die digitalen Fingerabdrücke der widerrufenen Zertifikate aufgelistet sind. Sie müssen bei der Gültigkeitsprüfung abgefragt werden.

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.

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.

Beschreibung der notwendigen Konfigurationseinstellungen für das "Common PKI" Zertifikatprofil

Nachfolgend eine Beschreibung, welche Konfigurationseinstellungen notwendig sind, damit eine auf den Active Directory Certificate Services basierende Zertifikathierarchie konform zum "Common PKI" Standard ist.

Erlaubte Relative Distinguished Names (RDNs) im Subject Distinguished Name (DN) ausgestellter Zertifikate

Grundsätzlich erlaubt das RFC 5280 die Verwendung beliebiger Zeichenketten im Subject Distinguished Name (DN) eines Zertifikats. Gängige Felder sind im Standard X.520 beschrieben. Die Längenbeschränkungen werden ebenfalls von der ITU-T empfohlen. Die heute gängigen Abkürzungen entstammen überwiegend dem RFC 4519.

Die Microsoft Active Directory Certificate Services erlauben in der Standardeinstellung jedoch nur bestimmte RDNs.

Folgende Relative Distinguished Names (RDNs) werden in der Standardeinstellung von der Active Directory Certificate Services (ADCS) Zertifizierungsstelle angenommen:

Die Wildcard Ausstellungsrichtlinie (All Issuance Policies) in ein Zertifizierungsstellen-Zertifikat aufnehmen

Installiert man eine ausstellende Zertifizierungsstelle (Issuing CA) und beantragt nicht explizit eine Ausstellungsrichtlinie (Issuance Policy) beinhaltet das resultierende Zertifizierungsstellen-Zertifikat keine Ausstellungsrichtlinien.

Möchte man die Wildcard Ausstellungsrichtline (All Issuance Policies) in das Zertifizierungsstellen-Zertifikat aufnehmen, muss wie folgt vorgegangen werden: