Windows Certificate Enrollment


Windows Certificate Enrollment

Rund um Zertifikate des Standards X.509 gibt es viele Missverständnisse und ebenso viele Vorurteile. Umfragen unter den Teilnehmern unserer regelmäßig durchgeführten Workshops (http://www.microsoft.com/de-at/services/PremierWorkshops.aspx) ergeben regelmäßig, dass sich des Themas PKI kaum jemand freiwillig annimmt. Nichts desto trotz wird der Einsatz von PKI-basierten Lösungen immer mehr zum Standard weshalb wir den TechNet Austria Blog um einige PKI Artikel bereichern möchten.

image

So oder so ähnlich stellen sich viele PKI Anwender den Ausrollprozess eines Zertifikates vor. Tatsächlich steckt  jedoch einiges mehr dahinter und es gilt einige Fragen zu klären.

 

Der Enrollment Prozess im Allgemeinen

Bevor wir uns den Windows Enrollment Methoden widmen, möchte ich daher zunächst den Enrollment Prozess unabhängig von Applikationen oder Betriebssystemen erläutern:

  1. Der Antragsteller erzeugt ein Schlüsselpaar, wobei der private Schlüssel das antragstellende Gerät nicht verlässt.
  2. Der Antragsteller erzeugt eine sog. Certificate Request (Certificate Signing Request, kurz CSR). Ein gängiges Format ist PKCS#10 (definiert in RFC 2986 – http://www.ietf.org/rfc/rfc2986.txt). Die CSR enthält unter anderem Informationen um den Antragsteller zu identifizieren, der Antrag wird anschließend mit Hilfe des privaten Schlüssels digital signiert.
  3. Die CSR wird an eine Registration Authority (RA) oder an die Zertifizierungsstelle selbst übermittelt.
  4. Die Zertifizierungsstelle überprüft die CSR (in Zusammenarbeit mit der RA) und stellt nach positiver Überprüfung das Zertifikat aus.

 

Windows Certificate Enrollment

Sowohl eine Active Directory integrierte Zertifizierungsstelle wie auch Windows Clients verfügen über verschiedene Möglichkeiten Zertifikate zu beantragen und auszurollen. Die wichtigsten sollen hier vorgestellt und erklärt werden.

 

Certificate Templates

Grundlage für alle in der Folge beschriebenen Szenarien sind Vorlagen: Eine Windows Active Directory integrierte Zertifizierungsstelle verwendet Vorlagen ("Certificate Templates") um es den Windows-basierten Antragstellern zu erleichtern, erfolgversprechende Anträge abzugeben. Diese Vorlagen enthalten Anweisungen in welchem Format und mit welchem Inhalt Anträge einzubringen sind. Z.B. mit welchem Algorithmus und welcher Länge und mit welchem CSP[1] (Cryptographic Service Provider) bzw. KSP (Key Storage Provider) das Schlüsselpaar zu erzeugen ist, welches Subject im Antrag zu stehen hat usw.

Certificate Templates werden im Active Directory gespeichert und den Active Directory integrierten Zertifizierungsstellen zugewiesen. Die CSR muss, das gilt für die Mehrheit der Enrollmentszenarien, zwingend die Information enthalten welches Certificate Template zu verwenden ist.

 

Ausrollen von Zertifikaten mit Hilfe von RPC/DCOM

Es ist naheliegend mit der am weitesten verbreiteten Methode zu beginnen. Der beschriebene Prozess kann entweder manuell oder automatisch (Autoenrollment) angestoßen werden.

1. Zunächst fragt ein Windows Domain-joined Client einige Informationen aus dem Active Directory ab:

a. Die Certificate Enrollment Policy[2] von einem DC der Root Domäne (UDP LDAP – CLDAP). Hierfür wird ein GetDCbyName Request gegen die Root Domain des Forest gemacht um die Root Domain Guid zu bekommen, die mit der Enrollment Policy assoziiert ist. Windows 7 und Windows 8 verhalten sich in diesem Zusammenhang nicht exakt gleich, siehe http://blogs.technet.com/b/instan/archive/2010/02/24/windows-7-attempts-to-make-ldap-queries-to-root-domain-during-enrollment-operations.aspx
b. pKICertificateTemplate objects (Certificate Templates) (LDAP Abfrage gegen einen DC aus der Domäne des Clients)
c. pKIEnrollmentService objects (AD integrierte Zertifizierungsstellen) (LDAP Abfrage gegen einen DC aus der Domäne des Clients)
d. msPKI-Enterprise-Oid(Object identifiers) (LDAP Abfrage gegen einen DC aus der Domäne des Clients)

2. Nun bestimmt der Client welche Zertifizierungsstellen basierend auf der enrollment policy verfügbar und welche Templates diesen zugeordnet sind.

3. Im nächsten Schritt wird durch einen Benutzer oder durch den Autoenrollmentprozess anhand der im Template konfigurierten Berechtigungen bestimmt, welches Template verwendet werden kann („Security Trimming“).

4. Ein Schlüsselpaar und die Certificate Request werden generiert.

5. Die CSR wird an das CertSrv Request DCOM Interface der Zertifizierungsstelle übermittelt (RPC/DCOM).

6. Die Zertifizierungsstelle überprüft den eingegangenen Antrag. Genauer gesagt wird diese Aufgabe vom Policy Module übernommen. Die Windows Zertifizierungsstelle bringt standardmäßig ein Policy Module mit, es können aber auch eigene „custom“ Policy Modules implementiert werden. Wie genau eingehende Anträge überprüft werden, hängt somit maßgeblich vom Policy Module[3] ab. Im Zuge dieser Prüfung vergleicht die Zertifizierungsstelle unter anderem das in der Request angegebene Subject gegen den Benutzer- bzw. Computernamen im AD, aber auch die Schlüssellänge oder Gültigkeitsdauer des Antrags.

7. Nach positiver Prüfung wird das Zertifikat an den Antragsteller gesandt (RPC/DCOM), vom Client im Certificate Store abgespeichert und mit dem zugehörigen privaten Schlüssel verknüpft[4].

 

Certificate Enrollment Web Services

Diese Methode existiert seit Windows 7 bzw. Windows Server 2008 R2. Vereinfacht gesagt, wird dabei der „normale“ Enrollment Prozess in TLS (Transport Layer Security) getunnelt. Diese Enrollment Methode unterstützt die folgenden Szenarien:

  • Ausrollen von Zertifikaten auf Windows Rechner ohne Domänenmitgliedschaft
  • Ausrollen von Zertifikaten auf Windows Rechner die Mitglied in einem anderen Forest als dem der Zertifizierungsstelle sind, auch wenn zwischen den Forest keine Trust-Beziehung besteht („Cross Forest Certificate Enrollment“)
  • Ausrollen von Zertifikaten auf Windows Rechner, die zwar eine Mitgliedschaft im Forest der Zertifizierungsstelle besitzen, mit diesem aber aufgrund von Einschränkungen im Netzwerk nicht direkt (d.h. nicht über LDAP und RPC/DCOM) kommunizieren können.

Diese Enrollment Methode erfordert die Implementierung von CEP (Certificate Enrollment Policy Server) und CES (Certificate Enrollment Service), beide Role Services von Active Directory Certificate Services. Nähere Informationen finden Sie auf http://blogs.technet.com/b/askds/archive/2010/02/01/certificate-enrollment-web-services.aspx

 

Übermitteln einer PKCS#10 Certificate Request

Selbstverständlich kann auch eine bereits bestehende Certificate Request an eine Windows Zertifizierungsstelle übermittelt werden. Wurde diese CSR auf einem nicht-Windows Gerät erstellt und enthält somit kein Certificate Template, muss diese Information hinzugefügt werden. Diese Aufgabe kann z.B. mit Hilfe von Certification Authority Web Enrollment https://technet.microsoft.com/en-us/library/hh831649.aspx) oder dem certreq.exe Utility https://technet.microsoft.com/en-us/library/cc736326(v=ws.10).aspx) erledigt werden.

 

Fazit

Eine Windows Zertifizierungsstelle unterstützt eine Vielzahl von Möglichkeiten Zertifikate auszurollen, wobei die hier vorgestellten nur einen kleinen Ausschnitt darstellen. Darüber hinaus gilt zu bedenken, dass das Ausrollen von Zertifikaten nicht nur ein technisches, sondern auch ein organisatorisches Thema ist. Vor allem dann wenn verschiedene Betriebssysteme beteiligt sind, gilt es zu klären wie die Schlüsselpaare und Certificate Requests erzeugt, zur CA transferiert und schließlich zurück zum Antragsteller gebracht werden. Aus diesem Grund ist es sinnvoll sich im Vorfeld mit den Anforderungen und Möglichkeiten der jeweiligen Endgeräte auseinander zu setzen.

 


[1] Ein CSP beinhaltet Implementierungen von kryptographischen Standards und Algorithmen und ist als eine besondere Variante von DLLs umgesetzt. Windows bringt bereits eine Reihe von CSPs mit, die die Ansteuerung der Algorithmen in Software oder in Hardware (z.B. für Smart Cards) enthalten. KSPs wiederum sind die Weiterentwicklung von CSPs und ergänzen die Möglichkeiten um die flexible Speicherung der privaten Schlüssel und um zusätzliche Algorithmen.

Eine Liste von Microsoft CSPs und KSPs gibt es hier: https://msdn.microsoft.com/en-us/library/aa386983.aspx

Weiterführende Informationen über CSPs finden Sie hier: https://msdn.microsoft.com/en-us/library/aa380245.aspx  

[2] Die „Certificate Enrollment Policy“ definiert wie der Enrollmentprozess im Detail durchgeführt wird. Die Certificate Enrollment Policy wird von der im Abschnitt “Certificate Enrollment Web Services” beschriebene Enrollment Methode benötigt.

[3] Certification Authority Policy Modules – https://msdn.microsoft.com/en-us/library/windows/desktop/aa387348(v=vs.85).aspx

[4] Dies gilt sofern Autoenrollment nicht explizit deaktiviert oder eine Rückbestätigung durch den „Certificate Manager“ erzwungen wurde.

 

 

 

Comments (1)
  1. Anonymous sagt:

    Von der Sicherheit privater Schlüssel – oder verstecken Sie den Haustürschlüssel immer noch unter der

Comments are closed.