CES und CEP sind zwei Rollendienste der Active Directory-Zertifikatdienste, die es Clients ermöglichen, Zertifikate über HTTPS anstatt über den herkömmlichen LDAP- und RPC/DCOM-Pfad zu beantragen. Der Zertifikatregistrierungsrichtlinien-Webdienst (CEP) teilt einem Client mit, welche Zertifikate er anfordern kann, und der Zertifikatregistrierungs-Webdienst (CES) übermittelt die Anfrage im Namen des Clients an die Zertifizierungsstelle. Zusammen erweitern sie die Microsoft- PKI auf Systeme, die die Zertifizierungsstelle oder Active Directory nicht direkt erreichen können.
Mit der zunehmenden Nutzung von Cloud-, Hybrid- und Remote-Umgebungen wird die Verwaltung herkömmlicher Zertifikatsregistrierung immer schwieriger. Systeme außerhalb des Unternehmensnetzwerks können die Active Directory-Zertifikatdienste (AD CS) oft nicht über die LDAP-, RPC- und DCOM-Protokolle erreichen, auf denen die domänenbasierte Registrierung beruht.
CEP und CES schließen diese Lücke. Sie wurden mit Windows Server 2008 R2 eingeführt und ermöglichen die Zertifikatsregistrierung über HTTPS, sodass Unternehmen Zertifikate für Systeme ausstellen und erneuern können, die nicht direkt mit der Zertifizierungsstelle oder Active Directory verbunden sind. Zu wissen, wie diese Dienste funktionieren und wann sie eingesetzt werden sollten, ist ein wesentlicher Bestandteil des Aufbaus einer skalierbaren und sicheren PKI.
Mit der Weiterentwicklung der PKI gewinnt dies noch mehr an Bedeutung: Das Update vom Mai 2026 für Windows Server 2025 führte die Unterstützung für Post-Quantum-Zertifikate (ML-DSA) in AD CS ein. Microsoft plant, die ML-DSA-Unterstützung in zukünftigen Updates auf CES, CEP und weitere AD CS-Rollendienste auszuweiten, sobald Unternehmen verstärkt Post-Quantum-Zertifikate einsetzen. Dieser Artikel erläutert die Webregistrierung, die Funktionen von CEP und CES, die zugrunde liegenden Protokolle, ihre jeweiligen Anwendungsfälle und die sichere Bereitstellung.
Was ist die Online-Anmeldung?
Bei der Web-Registrierung werden Zertifikate über HTTPS anstatt über herkömmliche domänenbasierte Mechanismen angefordert und empfangen.
In einer Standardumgebung mit Active Directory basiert die automatische Zertifikatsregistrierung auf Gruppenrichtlinien, LDAP und der direkten Kommunikation mit der ausstellenden Zertifizierungsstelle. Dies funktioniert gut für in die Domäne eingebundene Systeme, stößt jedoch bei Cloud-Workloads, Servern in Perimeternetzwerken, Arbeitsgruppengeräten und anderen Systemen mit eingeschränkter Anbindung an die interne Infrastruktur an ihre Grenzen. Die Webregistrierung löst dieses Problem, indem sie die Registrierung über HTTPS ermöglicht.
Clients kommunizieren mit Webdienst-Endpunkten anstatt direkt mit der Zertifizierungsstelle . Dies erhöht die Flexibilität bei gleichzeitiger Wahrung der Netzwerksegmentierung. Die beiden Dienste, die dies ermöglichen, sind CEP und CES, die jeweils eine spezifische Rolle im Registrierungsprozess übernehmen.
Was ist der CEP-Webdienst?
CEP stellt Kunden Informationen zu den Registrierungsrichtlinien bereit. Vor der Beantragung eines Zertifikats muss ein Kunde wissen, welche Zertifikatvorlagen verfügbar sind, welche Zertifizierungsstellen diese ausstellen können und welche Registrierungsanforderungen gelten. In einer herkömmlichen Umgebung werden diese Informationen über LDAP aus Active Directory bezogen.
CEP veröffentlicht dieselben Richtlinieninformationen über HTTPS mithilfe des Microsoft MS-XCEP- Protokolls. Dadurch kann ein Client seine Registrierungsoptionen ermitteln, ohne direkt auf Active Directory zugreifen zu müssen. CEP unterstützt verschiedene Authentifizierungsmethoden, darunter Kerberos, Benutzername und Kennwort sowie Clientzertifikatsauthentifizierung. Da Richtlinieninformationen zwischengespeichert werden, ist es möglich, dass neu veröffentlichte Vorlagen nicht sofort für Registrierungsclients verfügbar sind. Sobald der Client die Richtlinieninformationen hat, kann er eine Zertifikatsanforderung stellen. An diesem Punkt übernimmt CES.
Was ist der Zertifikatsregistrierungs-Webdienst?
CES führt die eigentliche Registrierung durch. Nachdem ein Client Richtlinieninformationen von CEP erhalten hat, sendet er seine Zertifikatsanforderung über HTTPS mithilfe des MS-WSTEP- Protokolls an CES. Dieses Protokoll basiert auf den WS-Trust X.509v3 Token Enrollment Extensions von Microsoft, die den WS-Trust 1.3-Standard erweitern. CES stellt dann über DCOM eine Verbindung zur ausstellenden Zertifizierungsstelle her, um die Registrierung im Namen des Clients abzuschließen, ruft das ausgestellte Zertifikat ab und sendet es an den Anforderer zurück.
Wenn CES auf einem separaten Server als die Zertifizierungsstelle (CA) ausgeführt wird, was die typische Bereitstellungsmethode ist, muss sein Dienstkonto für die eingeschränkte Kerberos-Delegierung konfiguriert werden, damit es Anfragen im Namen des Clients stellen kann; das Fehlen dieser Delegierung ist eine häufige Ursache für Registrierungsfehler.
Dadurch bleibt eine ausstellende Zertifizierungsstelle innerhalb eines internen Netzwerksegments geschützt, während Clients lediglich der Registrierungsdienst zugänglich ist. CES unterstützt außerdem die Zertifikatserneuerung , den Abruf ausstehender Anfragen und die schlüsselbasierte Erneuerung, bei der sich ein Client zur Erneuerung mit seinem bestehenden Zertifikat authentifiziert. Somit handelt es sich um einen vollständigen Registrierungsdienst und nicht nur um einen einfachen Anfrage-Proxy. Die folgende Tabelle stellt die wichtigsten Unterschiede zwischen CEP und CES einander gegenüber.
Vergleich von CES und CEP
| Funktion | CEP | CES |
|---|---|---|
| Zweck | Bietet Informationen zur Einschreibungspolitik. | Bearbeitet Zertifikatsanfragen |
| Protokoll | MS-XCEP | MS-WSTEP |
| Verbindet mit | Active Directory dient als Quelle für Richtlinien, die es Clients bereitstellt. | Die Zertifizierungsstelle, über DCOM |
| Kundentransport | HTTPS | HTTPS |
| Unterstützt die Einschreibung | Nein | Ja |
| Unterstützt Erneuerung | Nein | Ja |
| Authentifizierung | Kerberos, Benutzername und Passwort, Clientzertifikat | Kerberos, Benutzername und Passwort, Clientzertifikat |
| Typischer Anwendungsfall | Verfügbare Vorlagen, Zertifizierungsstellen und Anmelderegeln ermitteln | Einreichen und Erneuern von Zertifikatsanträgen |
Am einfachsten lässt sich der Unterschied so merken: CEP teilt den Clients mit, was sie anfordern können, während CES die Anfrage selbst bearbeitet.
Wann sollte man CES und CEP verwenden?
CES und CEP sind besonders nützlich, wenn die herkömmliche domänenbasierte automatische Registrierung nicht praktikabel ist. Typische Anwendungsfälle sind Cloud-basierte Workloads, Perimeter-Netzwerk- und DMZ-Server, Arbeitsgruppensysteme, von Partnern verwaltete Geräte, grenzüberschreitende oder gesamtstrukturübergreifende Bereitstellungen sowie segmentierte Netzwerke, in denen die Freigabe der RPC- und DCOM-Ports der Zertifizierungsstelle für Clients unerwünscht ist.
Organisationen, deren Systeme vollständig in die Domäne eingebunden sind und über eine zuverlässige Verbindung zu Active Directory und den ausstellenden Zertifizierungsstellen verfügen, können in der Regel die automatische Registrierung per Gruppenrichtlinie weiterhin nutzen , ohne diese Dienste bereitzustellen. Die Entscheidung hängt von der Konnektivität und den Vertrauensgrenzen ab, nicht vom Zertifikatsvolumen. Sobald die Entscheidung gefallen ist, ist es hilfreich, die häufigsten Probleme bei der Bereitstellung dieser Dienste zu kennen, um sie bereits in der Planungsphase zu vermeiden.
Häufige Herausforderungen bei der Bereitstellung
Die meisten Probleme bei der Webregistrierung treten in der CES- oder CEP-Schicht und nicht bei der Zertifizierungsstelle auf. Am häufigsten liegt die Ursache in unzureichenden Berechtigungen: Die von CES verwendete Identität muss für jede zu verarbeitende Zertifikatvorlage die entsprechenden Registrierungsberechtigungen, insbesondere die ACLs „Enroll“ und „Autoenroll“, besitzen.
Eine weitere häufige Fehlerursache ist die TLS- Konfiguration. Wenn ein Client dem vom CES- oder CEP-Endpunkt präsentierten Zertifikat nicht vertraut, schlägt die Anfrage fehl, bevor sie die Zertifizierungsstelle erreicht. Auch Authentifizierungsfehler verursachen Probleme, da sich ein System, das nicht in eine Domäne eingebunden ist, nicht an einem Endpunkt authentifizieren kann, der nur für Kerberos konfiguriert ist.
Eine fehlerhafte Konfiguration des Dienstprinzipalnamens (SPN) oder eine fehlende eingeschränkte Delegierung im CES-Konto sowie eine fehlerhafte HTTPS-Bindung oder eine nicht vertrauenswürdige Zertifikatskette auf dem IIS-Endpunkt sind weitere häufige Ursachen. Administratoren sollten zudem beachten, dass CEP Richtlinien zwischenspeichert, was die Veröffentlichung neu bereitgestellter Vorlagen verzögern kann. Die Berücksichtigung dieser Herausforderungen in der Planungsphase bildet die Grundlage für die Sicherheitskontrollen, die jede CES- und CEP-Bereitstellung begleiten sollten.
Sicherheitsüberlegungen
Da CES im Namen von Clients Anfragen an die Zertifizierungsstelle sendet, ist es eine sensible Komponente der PKI. Wenden Sie das Prinzip der minimalen Berechtigungen auf CES-Dienstkonten an, beschränken Sie die Registrierungsberechtigungen auf genehmigte Zertifikatvorlagen und erzwingen Sie moderne TLS-Konfigurationen an jedem Registrierungsendpunkt.
In Umgebungen mit hohen Sicherheitsanforderungen sollten die privaten Schlüssel der CES- und CEP-Endpunktzertifikate mit einem nach FIPS 140-3 Level 2 oder höher validierten Hardware-Sicherheitsmodul oder einem gleichwertigen hardwarebasierten Schlüsselspeicher geschützt werden. FIPS 140-3 Level 3 ist in der Regel für private CA-Schlüssel reserviert. Aktivieren Sie außerdem eine umfassende Protokollierung, damit Zertifikatsanforderungen, Ausstellungsereignisse und Registrierungsaktivitäten bei Bedarf zur Prüfung oder Untersuchung an ein SIEM-System weitergeleitet werden können.
Wie Verschlüsselungsberatung helfen kann
Die Einrichtung von CES und CEP umfasst mehr als die Installation zweier Rollendienste. Registrierungs-Workflows, Authentifizierungsmodelle, Netzwerksegmentierung, Zertifikatvorlagen und Sicherheitskontrollen müssen alle in die übergeordnete PKI-Architektur integriert werden, und Fehlkonfigurationen können unbemerkt zu Ausfällen und Lücken in der Auditierung führen.
Als auf Kryptografie spezialisiertes Beratungsunternehmen bietet Encryption Consulting (EC) maßgeschneidertes PKI-Know-how, das von großen Cybersicherheitsfirmen nicht erreicht wird. Mit seinen Enterprise PKI Services bewertet, entwirft, implementiert und sichert EC Microsoft PKI-Umgebungen. Dies umfasst die Gestaltung der CA-Hierarchie, die Verwaltung von Vorlagen, die Automatisierung des Zertifikatslebenszyklus, CA-Migrationen und Sicherheitsüberprüfungen der Webregistrierung.
Von der Bewertung und dem Design bis hin zur CP- und CPS-Dokumentation sorgt EC dafür, dass Ihre PKI jederzeit auditbereit ist und mit NIST , FIPS , eIDAS und WebTrust übereinstimmt. Dabei werden Root- und Subordinate-CA-Schlüssel durch FIPS 140-3 Level 3 HSMs geschützt und die Schlüsselzeremonien für Audit- und Wiederherstellungsbereitschaft dokumentiert.
Wenn die Zertifikatsregistrierung über CES und CEP hinaus skaliert werden muss, automatisiert CertSecure Manager , die Microsoft-PKI-native Zertifikatslebenszyklusmanagement-Plattform von EC, die Zertifikatserkennung, -ausstellung und -erneuerung im gesamten Netzwerk und schließt so die Lücken in der Transparenz und im Ablaufdatum, die zu Ausfällen führen können. Und während sich Unternehmen auf die Post-Quanten-Kryptographie vorbereiten , unterstützen die PQC-Beratungs- und Krypto-Agilitätsdienste von EC sie bei der Migration zu ML-DSA-basierten Zertifikaten, ohne dass die bestehende PKI neu strukturiert werden muss.
Fehlerhaftes Zertifikatsmanagement und der Ablauf von Anmeldeinformationen sind operative Risiken, die die Experten von EC erkennen und beheben, bevor sie zu Vorfällen führen. Ob Sie die Registrierung auf Cloud-Workloads ausweiten oder eine bestehende AD CS-Bereitstellung modernisieren – EC liefert unterbrechungsfrei, sodass digitales Vertrauen planmäßig aufgebaut und nicht dem Zufall überlassen bleibt.
Fazit
CES und CEP erweitern die Microsoft PKI über die herkömmliche domänenbasierte Zertifikatsregistrierung hinaus. CEP stellt die vom Client benötigten Registrierungsrichtlinien bereit, während CES die Zertifikatsanforderung verarbeitet und mit der Zertifizierungsstelle kommuniziert. Gemeinsam ermöglichen sie eine sichere Zertifikatsregistrierung über HTTPS, ohne die Zertifizierungsstelle direkt für Clients zugänglich zu machen.
Für Organisationen, die Cloud-Workloads , Remote-Systeme, segmentierte Netzwerke oder übergreifende Szenarien unterstützen, sind CES und CEP weiterhin praktische Werkzeuge zur sicheren Erweiterung der PKI. Ein sinnvoller erster Schritt besteht darin, zu ermitteln, welche Systeme derzeit keine standardmäßige automatische Registrierung nutzen können und warum. Anschließend sollten die CES- und CEP-Implementierung, das Authentifizierungsmodell und die Vorlagenberechtigungen entsprechend diesen spezifischen Vertrauensgrenzen konzipiert werden, bevor die Implementierung erfolgt.
