Mit Windows Server 2008 R2 und Windows 7 wurde eine neue Funktionen für die Beantragung von Zertifikaten eingeführt: Die Certificate Enrollment Web Services, welche durch zwei Serverrollen abgebildet werden:
- Certificate Enrollment Policy Web Service (CEP)
- Certificate Enrollment Web Services (CES)
Nachfolgend werden die Hintergedanken zu diesen Rollen, ihre Funktionsweise sowie die möglichen Einsatzszenarien beschrieben.
Klassische Zertifikatbeantragung über LDAP und RPC/DCOM
Die Funktionsweise der klassischen Zertifikatbeantragung über RPC/DCOM ist in diesem Artikel beschrieben, welcher zuerst gelesen werden sollte, um die gemeinsamen Grundlagen zu verstehen.
Zusammengefasst besteht die klassische Zertifikatbeantragung aus zwei wesentlichen Schritten:
- Abfrage des Active Directory über das LDAP-Protokoll nach für die Zertifikatbeantragung relevanten Informationen (Zertifikatvorlagen, und welche Zertifizierungsstellen sie zur Beantragung anbieten.
- Senden der Zertifikatanforderung über RPC/DCOM an die ermittelte zuständige Zertifizierungsstelle.
Diese Methode hat jedoch einige Nachteile:
- Sie funktioniert nur im internen Netzwerk.
- Es ist eine Domänenkonnektivität erforderlich.
- Es ist eine Mitgliedschaft in der gleichen Active Directiory Gesamtstruktur, oder eine Vertrauensstellung inklusive Replikation der relevanten Daten notwendig.
- Es ist erforderlich, dass die RPC/DCOM Netzwerkports gegenüber allen Antragstellern exponiert werden müssen, was ein Sicherheitsrisiko darstellen kann.
- Die Authentifizierung an der Zertifizierungsstelle muss über Kerberos erfolgen.
Zertifikatbeantragung über die Certificate Enrollment Web Services
Bislang erfolgte die Beantragung von Zertifikaten klassisch über Lightweight Directory Access Protocol (LDAP) und Remote Procedure Call / Distributed Common Object Model (RPC/DCOM). Hierfür war eine Verbindung der Clients (alle Entitäten, die Zertifikate von einer Zertifizierungsstelle beantragen) zu diesen Netzwerkports im internen Netzwerk notwendig.
Die Certificate Enrollment Web Services, bestehend aus dem Certificate Enrollment Policy Web Service (CEP) und dem Certificate Enrollment Web Service (CES) ermöglichen nun die Beantragung über eine HTTPS-Schnittstelle.
Dies ermöglich neue Einsatzszenarien wie beispielsweise:
- Antragsteller, welche über das Internet Zertifikate beantragen oder erneuern sollen.
- Antragsteller, welche sich in einer anderen Gesamtstruktur befinden, zu der es keine Vertrauensstellung gibt.
- Antragsteller in einer demilitarisierten Zone (DMZ).
- Antragsteller im internen Netzwerk, jedoch ohne die RPC/DCOM Ports der Zertifizierungsstelle gegenüber dem Netzwerk exponieren zu müssen.
- Authentifizierung neben Kerberos nun auch mit Benutzername/Kennwort sowie Client-Zertifikat.
- Die Möglichkeit, sich für die Erneuerung eines Zertifikates mit dem vorigen Zertifikat zu authentifizieren (Key based Renewal).
Schritt 1: Verbindung des Antragstellers zum CEP über HTTPS
Der Antragsteller verbindet sich zum Certificate Enrollment Policy Service über HTTPS. Die Information, wo sich dieser befindet, wird ihm per Gruppenrichtlinie über eine Enrollment Policy mitgeteilt.
Der Antragsteller authentifiziert sich gegenüber dem CEP über eine der drei folgenden Methoden:
- Benutzername und Kennwort
- Kerberos
- Client-Zertifikat
Schritt 2: Verbindung des CEP zum Active Directory über LDAP
Der CEP übernimmt stellvertretend für den Client die LDAP-Abfrage gegen das Active Directory. Es werden folgende Informationen abgefragt.
- Alle pKICertificateTemplate Objekte (Zertifikatvorlagen) in der Active Directory Gesamtstruktur.
- Alle pKIEnrollmentService Objekte (Enterprise Zertifizierungsstellen) in der Active Directory Gesamtstruktur.
- Alle msPKI-Enterprise-Oid Objekte (Object Identifier) in der Active Directory Gesamtstruktur.
Diese Informationen sind allesamt in der Configuration Partition der Active Directory Gesamtstruktur gespeichert.
Anhand der pKICertificateTemplate und msPKI-Enterprise-OID Objekte kann ermittelt werden, ob der Antragsteller zur Beantragung ("Enroll") berechtigt ist und ob eine automatische Beantragung zu erfolgen hat ("Auto-Enroll"). Ebenso werden hierüber die Voreinstellungen für das Stellen der Zertifikatanforderung ermittelt.
Anhand der pKIEnrollmentService Objekte können die Zertifizierungsstellen ermittelt werden, welche die zu beantragenden Zertifikatvorlagen anbieten, sowie über welchen Certificate Enrollment Web Services die Zertifizierungsstelle erreichbar ist. Hierzu werden die Attribute certificateTemplates sowie msPKI-Enrollment-Servers ausgewertet.
Schritt 3: Verbindung des Antragstellers zum CES über HTTPS
Im dritten Schritt werden anhand der abgefragten Informationen ein Schlüsselpaar sowie eine Zertifikatanforderung generiert, und an den zuständigen CES Server mittels HTTPS gesendet.
Der Antragsteller authentifiziert sich gegenüber dem CES wieder über eine der drei folgenden Methoden:
- Benutzername und Kennwort
- Kerberos
- Client-Zertifikat
Schritt 4: Verbindung des CES zur Zertifizierungsstelle über RPC/DCOM
Der CES impersoniert nun den angemeldeten Benutzer und führt in dessen Sicherheitskontext die Beantragung des Zertifikats über RPC/DCOM durch.
Die Zertifizierungsstelle kann den Benutzer aufgrund der impersonierten Kerberos-Authentifizierung identifizieren und wendet mit ihrem Policy-Modul die in der entsprechenden Zertifikatvorlage vorgegebenen Einstellungen an.
Nach Ausstellung des Zertifikats liefert der CES das Zertifikat an den Antragsteller zurück.
Weiterführende Links:
Externe Quellen
- Certificate Enrollment Web Services (Microsoft)
Deutsch 
English
6 Gedanken zu „Grundlagen Zertifikatbeantragung über Certificate Enrollment Web Services (CEP, CES)“
Kommentare sind geschlossen.