Ihr ultimativer Leitfaden zum Verständnis von CEP und CES

Wenn Sie es schaffen, a Windows Server Public-Key-Infrastruktur (PKI) In einer Umgebung außerhalb Ihres Domänennetzwerks ist die Zertifikatsregistrierung einer der betriebskritischsten und gleichzeitig fehleranfälligsten Prozesse in Ihrer Infrastruktur. Befinden sich Geräte außerhalb Ihres Domänennetzwerks, funktioniert die herkömmliche Zertifikatsregistrierung über Active Directory schlichtweg nicht. Genau das ist das Problem, das Webdienst für Richtlinien zur Zertifikatsanmeldung (CEP) als auch Webdienst für die Zertifikatsregistrierung (CES) wurden entwickelt, um zu lösen.

Diese beiden Active Directory-Zertifikatdienste (AD CS) arbeiten zusammen, um eine sichere und automatisierte Zertifikatregistrierung für jedes Gerät zu ermöglichen – unabhängig davon, ob es in die Domäne eingebunden, remote verbunden, in einer Cloud-Hybridumgebung oder außerhalb des internen Netzwerkperimeters ist. Im Folgenden werden die einzelnen Komponenten erläutert und der automatische Registrierungsprozess mithilfe von CEP und CES erklärt.

Was ist der Certificate Enrollment Policy Web Service (CEP)?

Der Webdienst für Zertifikatsregistrierungsrichtlinien (CEP) ist der AD CS-Rollendienst, der für die Bereitstellung von Zertifikatsregistrierungsrichtlinien an Clients über eine sichere Webschnittstelle zuständig ist. Er fungiert als Richtlinienverteilungsstelle Ihrer PKI-Umgebung.

In einer typischen Domänenkonfiguration bezieht ein Windows-Computer, der der Domäne beigetreten ist, automatisch und ohne manuelle Eingriffe Zertifikatsinformationen von Active Directory. Er fragt Active Directory im Wesentlichen, welche Zertifikate er anfordern darf, welche Zertifikatvorlagen verfügbar sind und welche Zertifizierungsstellen (CAs) Anhand dieser Informationen kann der Rechner das Zertifikat dann automatisch anfordern und installieren. Dies geschieht alles im Hintergrund, sodass der Vorgang für den Benutzer unsichtbar ist.

Dieser traditionelle Ansatz funktioniert in modernen Umgebungen nicht mehr, in denen Systeme nicht direkt mit Active Directory kommunizieren können. Zum Beispiel:

• Fernarbeiter Verbindung über das Internet ohne VPN
• Nicht in die Domäne eingebundene Geräte die keine AD-Konnektivität haben
• DMZ-Server sind vom internen Bereich isoliert
• Cloud-Workloads in Azure-, AWS-, Hybridumgebungen oder sogar Partner-/Anbietersystemen
• Geräte von Partnern oder Lieferanten die Organisationszertifikate benötigen

Da sie Active Directory nicht abfragen können, können sie weder Zertifikatvorlagen noch verfügbare Zertifizierungsstellen ermitteln, was den normalen automatischen Registrierungsprozess unterbricht. Genau hier kommen Lösungen wie CEP und CES ins Spiel, da sie diesen externen oder isolierten Systemen eine sichere, webbasierte Möglichkeit bieten, Zertifikate anzufordern und zu empfangen.

CEP behebt dieses Problem, indem es die Richtlinien für die Zertifikatsanmeldung über einen sicheren Zugang bereitstellt. HTTPS-Webdienst Anstatt direkten Zugriff auf Active Directory zu benötigen, kann ein autorisierter Client, selbst wenn er sich außerhalb des internen Netzwerks befindet oder nicht der Domäne angehört, über das Web eine Verbindung zum CEP herstellen und abfragen, welche Zertifikate er anfordern darf, welche Vorlagen verfügbar sind und welche Zertifizierungsstelle er verwenden soll. Vereinfacht gesagt, fungiert das CEP als sicherer Online-Ersatz für die Richtlinienabfragefunktion von Active Directory und ermöglicht es entfernten oder isolierten Systemen, die benötigten Informationen zur Zertifikatregistrierung zu erhalten.

Welche Informationen liefert CEP?

Wenn sich ein Client mit CEP verbindet, sendet CEP alle für diesen Client geltenden Zertifikatsregistrierungsregeln und -optionen zurück. Dazu gehören:

• Alle Zertifikatvorlagen dass der Kunde die Nutzung gestattet ist
• Vorlagenspezifisch Einstellungen oder Einschränkungen, wie Schlüsselverwendung oder Fachanforderungen
• Das Zielzertifizierungsbehörde dass der Kunde Anfragen an
• Konfiguration der Anmelderichtlinie einschließlich Erneuerungsschwellen und Gültigkeitszeiträumen
• Authentifizierungsanforderungen Der Kunde muss bei der Einreichung einer Anfrage die folgenden Bedingungen erfüllen:
• Richtlinienmetadaten, einschließlich der eindeutigen Kennung der Anmelderichtlinie.

Hinweis: CEP stellt lediglich Informationen zur Zertifikatsregistrierungsrichtlinie bereit; es informiert den Kunden darüber, welche Zertifikate er beantragen darf und unter welchen Bedingungen. CEP stellt keine Zertifikate aus, bearbeitet Registrierungsanträge, kommuniziert nicht mit der Zertifizierungsstelle, um einen Antrag einzureichen, und speichert keine Zertifikatsdaten. Kurz gesagt: CEP ist lediglich ein Leitfaden; es informiert den Kunden, führt aber nicht die eigentliche Zertifikatsregistrierung durch.

Was ist der Certificate Enrollment Web Service (CES)?

Das Webdienst für die Zertifikatsregistrierung (CES) ist das AD CS Dieser Rollendienst wickelt die eigentlichen Zertifikatsregistrierungs- und -verlängerungstransaktionen ab. Er setzt genau dort an, wo CEP aufhört, und fungiert als sicherer, authentifizierter Vermittler zwischen dem Client und der Backend-Zertifizierungsstelle.

Selbst nachdem der Client von CEP erfahren hat, welches Zertifikat er anfordern darf, muss er es dennoch tatsächlich senden. Anforderung Das Zertifikat muss an eine Zertifizierungsstelle (CA) gesendet werden, damit es ausgestellt werden kann. In einer normalen internen Domänenumgebung geschieht dies durch direktes Senden der Anfrage an die CA mittels DCOM/RPC. Dies funktioniert jedoch nur, wenn der Client über eine direkte Netzwerkverbindung zur CA verfügt. Für Remote-Benutzer, internetbasierte Geräte oder isolierte Systeme stellt dies ein Problem dar, da sie die CA in der Regel nicht direkt erreichen können.

CES löst dieses Problem, indem es als sichere Zwischenschicht fungiert: Der Client sendet die Zertifikatsanforderung über HTTPS an CES, und CES leitet sie dann an die interne Zertifizierungsstelle des Clients weiter. Dadurch kann der Client weiterhin Zertifikate beantragen, ohne jemals direkten Zugriff auf die Zertifizierungsstelle selbst zu benötigen.

Rolle von CES

• Nimmt Anträge auf Zertifikatsausstellung und -verlängerung von Kunden über HTTPS
• Authentifiziert den Client vor der Bearbeitung einer Anfrage
• Authentifizierte Anfragen weitergeleitet an die interne Zertifizierungsstelle
• Gibt CA-Antworten zurück – ausgestelltes Zertifikat, ausstehender Status oder Ablehnung – Rückmeldung an den Kunden
• Griffe Zertifikatserneuerung einschließlich schlüsselbasierter Erneuerung für automatisierte Szenarien
• Erhält die vollständige Anmeldetransaktion von der Einreichung bis zur Antwort

Dieses Design ist wichtig, da es die interne Zertifizierungsstelle vor direkter Erreichbarkeit durch externe Systeme schützt. Die Zertifizierungsstelle benötigt weder eine öffentliche IP-Adresse noch muss sie aus dem Internet erreichbar sein, was das Sicherheitsrisiko erheblich reduziert. Stattdessen fungiert CES als sicherer Gatekeeper vor der Zertifizierungsstelle. Es prüft zunächst Authentifizierung und Autorisierung, sodass nur gültige und genehmigte Anfragen an die Zertifizierungsstelle weitergeleitet werden.

Dadurch wird CES zu einem kontrollierten Zugangspunkt für die Zertifikatsregistrierung, während die Zertifizierungsstelle (CA) sicher dahinter verborgen bleibt. Dies verbessert auch die Nachvollziehbarkeit, da sowohl CES als auch die CA Aktivitäten separat protokollieren und prüfen können. So wird besser sichtbar, wer eine Anfrage gestellt hat und wie diese bearbeitet wurde.

Endgültiger Vergleich zwischen CEP und CES

CEP teilt dem Kunden mit, was er anfordern soll. CES hilft dem Kunden dabei, die Anforderung tatsächlich zu stellen.

Lassen Sie uns die Gemeinsamkeiten und Unterschiede zwischen CEP und CES verstehen.

CEP (Webdienst für Richtlinien zur Zertifikatsanerkennung)	CES (Webdienst zur Zertifikatseinschreibung)
Stellt den Kunden Richtlinien zur Zertifikatsanmeldung zur Verfügung.	Bearbeitet Anträge auf Zertifikatserteilung und -verlängerung.
Teilt dem Client mit, welche Zertifikate er anfordern kann.	Ermöglicht es dem Client, die Anfrage tatsächlich abzusenden.
Kommuniziert NICHT mit der Zertifizierungsstelle	Kommuniziert mit der Zertifizierungsstelle
Stellt keine Zertifikate aus.	Stellt keine Zertifikate aus (vermittelt an eine Zertifizierungsstelle).
Rückgabevorlagen, Einstellungen und Richtliniendetails	Bearbeitet und leitet Zertifikatsanfragen weiter
Kundenorientierter Service	Kundenorientierter Service
Erfordert IIS	Erfordert IIS
Erfordert Authentifizierung	Erfordert Authentifizierung
Unterstützt Kerberos- und Benutzername/Passwort-Authentifizierung	Unterstützt Kerberos-, Benutzername/Passwort- und Zertifikatsauthentifizierung.
Unterstützt keine zertifikatsbasierte Authentifizierung	Unterstützt die Zertifikatsauthentifizierung (hauptsächlich zur Erneuerung)
Wird verwendet, um Richtlinien remote abzurufen	Wird zur Durchführung der Fernregistrierung verwendet
Verwendet HTTPS (Port 443)	Verwendet HTTPS (Port 443)

Schritt-für-Schritt-Anleitung zur Funktionsweise der automatischen Zertifikatsregistrierung

Nachfolgend ist der vollständige End-to-End-Workflow für die automatische Zertifikatsregistrierung mit CEP und CES in einer Active Directory-Unternehmensumgebung dargestellt.

Schritt 1 – Der Kunde ergreift die Initiative: Er kontaktiert CEP bezüglich der Anmelderichtlinien.

Der Workflow beginnt, wenn ein Client, z. B. eine Windows-Workstation, ein Server oder ein Remote-Gerät, feststellt, dass er ein Zertifikat registrieren oder ein ablaufendes Zertifikat erneuern muss. Dieser Auslöser kann folgende sein:

• Automatische Anmeldung zu Gruppenversicherungen (geplante Zertifikatsprüfung)
• Manuelle Registrierung initiiert von einem Benutzer oder Administrator
• Automatische Verlängerung Ausgelöst durch das Erreichen des Ablaufdatums des Zertifikats.
• Erstmalige Einschreibung auf einem neuen Gerät, das bereitgestellt wird

Der Kunde wendet sich an den CEP-Endpunkt über HTTPS um die Registrierungsrichtlinie abzurufen. Zu diesem Zeitpunkt wurde noch keine Zertifikatsanforderung gestellt. Der Client fragt lediglich: „Was darf ich beantragen und welche Regeln gelten?“

Dieser Schritt ist für entfernte und nicht in die Domäne eingebundene Geräte von entscheidender Bedeutung, da sie keinen anderen Mechanismus zur Ermittlung verfügbarer Zertifikatvorlagen und CA-Informationen haben.

Schritt 2 – Antwort des CEP: Rückgabebestimmungen

Wenn ein Kunde CEP kontaktiert, analysiert CEP die Kundendaten und sendet die exakt zutreffende Zertifizierungsrichtlinie zurück. Diese Antwort umfasst:

• Komplette Liste von Zertifikatvorlagen Der Kunde ist zur Nutzung berechtigt
• Vorlagenspezifische Einstellungen, einschließlich Anforderungen an die Schlüssellänge, Gültigkeitsdauer, Verlängerungsschwelle, Konfiguration des Subjektnamens und Kennzeichnungen für die Schlüsselverwendung
• Zielzertifizierungsbehörde Informationen – die Zertifizierungsstelle, an die der Kunde Anfragen richten soll.
• Konfiguration der Registrierungsrichtlinie — Verhalten bei der automatischen Anmeldung, Einstellungen für die Verlängerung
• Richtlinien-ID — die eindeutige Kennung, die die Richtlinie mit ihrer Quelle verknüpft

Vereinfacht ausgedrückt dient diese Antwort als vollständige Bedienungsanleitung, anhand derer der Client eine gültige und konforme Zertifikatsanforderung erstellen kann.

Schritt 3 – Erstellt die Zertifikatsanforderung

Anhand der Richtlinienantwort des CEP erstellt der Client die Zertifikatsanforderung. Dies umfasst Folgendes:

• Erzeugen eines kryptografischen Schlüsselpaares — öffentlicher und privater Schlüssel unter Verwendung des im Template angegebenen Algorithmus und der Schlüssellänge (RSA 2048, RSA 4096 oder ECC)
• Aufbau der Zertifikatsignierungsanfrage (CSR) im PKCS#10-Format
• Auswahl der Zertifikatvorlage das den Bedürfnissen des Kunden entspricht
• Das Feld „Betreff“ ausfüllen — typischerweise der Rechnername, der Benutzer-UPN oder ein benutzerdefinierter Betreff basierend auf der Vorlagenkonfiguration
• Hinzufügen alternativer Subjektnamen (SANs) — DNS-Namen, IP-Adressen oder UPNs je nach Bedarf
• Anwenden von vorlagendefinierten Erweiterungen — Tastenbelegung, Erweiterte Tastenbelegung CDP, AIA

Der Client nutzt die Richtlinienantwort des CEP, um sicherzustellen, dass die Anfrage genau dem entspricht, was die Zertifizierungsstelle akzeptiert.

Schritt 4 – Anfrage an CES senden

Sobald die Zertifikatsanforderung vorbereitet ist, sendet der Client sie über HTTPS an den CES-Endpunkt. Diese Anforderung befindet sich in PKCS#10-Format und umfasst die erforderliche Authentifizierungsmethode, beispielsweise ein Kerberos-Ticket, Benutzername/Passwort oder ein Clientzertifikat, je nach Konfiguration von CES. Ab diesem Zeitpunkt übernimmt CES die aktive Verarbeitungsschicht. Der Client hat seinen Teil erledigt und wartet nun, während CES die Authentifizierung durchführt, die Anfrage an die Zertifizierungsstelle weiterleitet und den Registrierungsprozess abschließt.

Schritt 5 – Authentifiziert den Client und leitet die Anfrage an die Zertifizierungsstelle weiter

Dies ist der sicherheitskritischste Schritt im gesamten Arbeitsablauf. CES führt zwei Operationen nacheinander aus:

Authentifizierung: CES überprüft die Identität des Clients anhand der konfigurierten Authentifizierungsmethode. Bei Kerberos wird das Service-Ticket überprüft. Bei Benutzername/Passwort werden die Anmeldeinformationen überprüft. Active DirectoryBei der zertifikatsbasierten Erneuerung wird das bestehende Zertifikat validiert. Erst nach erfolgreicher Authentifizierung wird eine Anfrage weitergeleitet.

Weiterleitung: Nach erfolgreicher Authentifizierung ordnet CES die authentifizierte Identität der entsprechenden Zertifizierungsstelle (CA) zu und leitet die Zertifikatsanforderung weiter. CES nutzt sein Backend-Dienstkonto und die Konfiguration der CA-Kommunikation, um die Anforderung sicher an die interne CA weiterzuleiten, zu der der Client keinen direkten Zugriff hat.

Schritt 6 – Bearbeitung der Zertifikatsanfrage

Wenn CES die Zertifikatsanforderung weiterleitet, wertet die Zertifizierungsstelle (CA) diese selbstständig anhand ihrer konfigurierten Regeln und Richtlinien aus, wie zum Beispiel:

• Zertifikatvorlagenberechtigungen — Ist diese Identität berechtigt, sich für diese Vorlage anzumelden?
• Ausstellungsanforderungen — Erfüllt die Anfrage alle erforderlichen Attribute?
• CA-Richtlinie — Gibt es irgendwelche Beschränkungen auf Ebene Kaliforniens?
• Einstellungen für die Managergenehmigung — Ist für diese Vorlage eine manuelle Genehmigung erforderlich?

Auf Grundlage dieser Prüfungen trifft die CA eine Entscheidung: Probleme das Zertifikat, falls alles gültig ist, ausstehend die Anfrage, ob eine manuelle Genehmigung erforderlich ist, oder leugnet wird es ausgelöst, wenn der Antragsteller nicht berechtigt ist oder die Anfrage die erforderlichen Kriterien nicht erfüllt.

Schritt 7 – Übermittlung der CA-Antwort an den Kunden

Nachdem die Zertifizierungsstelle eine Entscheidung getroffen hat, sendet CES das Ergebnis über HTTPS an den Client zurück. Die Ergebnisse können wie folgt aussehen:

• Wenn die Anfrage ist ausgegebenCES gibt das fertige, signierte Zertifikat zurück, typischerweise in PKCS#7-Formatdamit der Kunde es installieren und verwenden kann.
• Wenn die Anfrage ist schwebendCES sendet eine Antwort zurück Anfrage ID zusammen mit einem ausstehenden Status, der es dem Kunden ermöglicht, später noch einmal nach dem Endergebnis zu suchen.
• Wenn die Anfrage ist verweigertCES liefert die relevanten Fehlercode und der Grund für die Ablehnungdamit der Kunde oder Administrator nachvollziehen kann, warum das Zertifikat nicht ausgestellt wurde.

CES empfängt die Entscheidung der Zertifizierungsstelle und leitet sie über HTTPS an den ursprünglichen Client zurück:

• Ausgegeben: CES gibt das vollständige signierte Zertifikat im PKCS#7-Format zurück.
• Steht aus: CES gibt eine RequestID und den Status "ausstehend" zurück, sodass der Client den Abschluss abfragen kann.
• Bestritten: CES gibt den Fehlercode und den Ablehnungsgrund zurück.

Schritt 8 – Der Client empfängt und installiert das Zertifikat

Sobald die Zertifikatsanforderung verarbeitet wurde, erhält der Client das Ergebnis. Wird die Anforderung genehmigt, wird das Zertifikat automatisch im entsprechenden Windows-Zertifikatspeicher installiert. Lokaler Rechner\Persönlich für Computerzertifikate und Aktueller Benutzer\Persönlich Für Benutzerzertifikate ist das System automatisch voreingestellt und sofort einsatzbereit. Befindet sich die Anfrage noch in Bearbeitung (z. B. wartet sie auf Genehmigung), läuft der Prozess weiter: Die automatische Registrierung prüft CES regelmäßig, bis eine endgültige Entscheidung getroffen wurde. Wird die Anfrage abgelehnt, wird dies in den Systemprotokollen vermerkt, sodass Administratoren die Fehlerursache analysieren und gegebenenfalls Maßnahmen ergreifen können.

Aufschlüsselung der Kerberos-Authentifizierung in CEP und CES

Kerberos ist ein sicheres, ticketbasiertes Authentifizierungssystem, das in Active Directory verwendet wird und es Benutzern oder Computern ermöglicht, ihre Identität nachzuweisen, ohne Passwörter über das Netzwerk zu senden. Es funktioniert über einen vertrauenswürdigen Dienst namens Key Distribution Center (KDC), der auf Domänencontrollern ausgeführt wird.

Im Folgenden werden die Schritte zur Funktionsweise der Kerberos-Authentifizierung beschrieben:

Wenn sich ein Benutzer an einem in eine Domäne eingebundenen Windows-Rechner anmeldet, startet die Kerberos-Authentifizierung automatisch im Hintergrund:

• Der Client sendet eine AS-REQ (Authentifizierungsdienstanforderung) zu den Schlüsselverteilungszentrum (KDC), das auf dem Domänencontroller läuft.
• Der KDC überprüft die Identität des Clients anhand des in Active Directory gespeicherten Anmeldeinformationshashs (für ein Benutzer- oder Computerkonto).
• Sind die Anmeldeinformationen gültig, stellt der KDC eine Ticket Granting Ticket (TGT).
• Dieses TGT ist verschlüsselt mit dem geheimen Schlüssel des KDCum sicherzustellen, dass es nicht gefälscht oder manipuliert werden kann.
• Der Client speichert das TGT sicher im Speicher innerhalb LSASS (Subsystem Service der lokalen Sicherheitsbehörde)Es wird niemals auf die Festplatte geschrieben.

Wenn der Kunde CEP oder CES kontaktieren muss (z. B. zur Zertifikatsanmeldung oder zum Abruf von Versicherungsunterlagen):

• Der Client sendet eine TGS-REQ (Ticket Granting Service Request) zum KDC.
• Es umfasst seine TGT und beantragt den Zugriff auf einen bestimmten Dienst, der durch die Dienstprinzipalname (SPN) von CEP oder CES.
• Der KDC sucht diesen SPN in Active Directory und identifiziert den zugehörigen SPN. Dienstkonto CEP/CES wird ausgeführt (typischerweise eine IIS-Anwendungspoolidentität).
• Der KDC generiert einen Serviceticket, Das ist verschlüsselt mit dem geheimen Schlüssel des DienstkontosDas bedeutet, dass nur dieser Dienst es entschlüsseln kann.
• Das Service-Ticket wird an den Client zurückgesendet und temporär im Speicher abgelegt.

Wenn der Client tatsächlich eine Verbindung zu CEP oder CES herstellt:

• Es sendet die Serviceticket als Teil der HTTPS-Anfrage unter Verwendung der HTTP Negotiate/Kerberos-Autorisierungsheader.
• IIS (das CEP/CES hostet) empfängt die Anfrage und versucht, das Ticket mithilfe des Anmeldeinformationen des Anwendungspool-Dienstkontos.
• Nach der Entschlüsselung enthüllt das Ticket Folgendes:
  1. Clientidentität (Benutzername oder Computerkonto)
  2. Domain-Informationen
  3. Gruppenmitgliedschaften
  4. Sitzungsschlüssel für sichere Kommunikation

• CEP/CES validiert anschließend das Ticket:
  1. Stellt sicher, dass das Ticket authentisch und unverfälscht
  2. Überprüft die ZeitstempelEs muss innerhalb des zulässigen Bereichs liegen. 5-Minuten-Uhrabweichungstoleranz
  3. Prüft, ob das Ticket noch gültig ist (nicht abgelaufen).

Die Kerberos-Authentifizierung ist so konzipiert, dass sie für den Endbenutzer völlig transparent ist; es gibt keine Aufforderungen oder manuellen Eingaben, da die Authentifizierung automatisch im Hintergrund unter Verwendung der angemeldeten Domänenidentität erfolgt.

Es funktioniert nativ für alle in eine Domäne eingebundenen Windows-Rechner und -Benutzer, wobei das Rechner- oder Benutzerkonto in Active Directory als Authentifizierungsidentität dient. Die von Kerberos ausgestellten Tickets sind zeitlich begrenzt und in der Regel etwa 10 Stunden gültig (konfigurierbar über Gruppenrichtlinien), wodurch ein ausgewogenes Verhältnis zwischen Sicherheit und Benutzerfreundlichkeit gewährleistet wird.

Allerdings ist Kerberos an strenge Bedingungen geknüpft: Die Uhren von Client und Server müssen innerhalb eines kurzen Zeitfensters (in der Regel 5 Minuten) synchronisiert sein, und der Client muss über eine Netzwerkverbindung zu einem Domänencontroller verfügen, um Tickets zu erhalten und zu erneuern.

Wann sollte man Kerberos verwenden?

Kerberos-Authentifizierung für CEP und CES bereitstellen, wenn:

• Alle angemeldeten Kunden sind in die Domäne eingebundene Windows-Computer
• Sie führen eine Bereitstellung durch Automatische Anmeldung zu Gruppenversicherungen für Computer- oder Benutzerzertifikate
• Kunden haben zuverlässige Verbindung mit geringer Latenz zu einem Domänencontroller
• Der primäre Anwendungsfall ist Automatische Maschinenzertifikatsregistrierung
• Maximale Sicherheitsstufe ohne Offenlegung von Zugangsdaten erforderlich
• Sie wollen völlig geräuschlos, keine Interaktion Zertifikatslebenszyklusverwaltung
• Ihre Umgebung ist eine Einzelwald oder verfügt über gut etablierte, waldübergreifende Kerberos-Treuhandschaften
• Sie stellen eine Anwendung über ein internes Unternehmensnetzwerk oder ein erzwungenes Split-Tunnel-VPN

Aufschlüsselung der Benutzername/Passwort-Authentifizierung in CEP/CES

Benutzername/Passwort-Authentifizierung in CEP als auch CES wird verwendet, wenn der Client nicht auf Kerberos vertrauen kann, normalerweise weil er nicht in eine Domäne eingebunden, stellt eine Verbindung von einem her externes Netzwerkoder keine direkte Verbindung zu einem Domänencontroller hat.

Hinweis: Wenn in der Microsoft-Dokumentation auf Folgendes verwiesen wird Benutzername/Passwort-Authentifizierung Für den Certificate Enrollment Policy Web Service (CEP) und den Certificate Enrollment Web Service (CES) bezieht sich dies speziell auf HTTP-Basisauthentifizierung, ein standardisiertes Authentifizierungsschema, das in RFC 7617, das über eine HTTPS-Transportschicht arbeitet.

In diesem Modell gibt der Client manuell einen Benutzernamen und ein Passwort an, und diese Anmeldeinformationen werden über den CEP- oder CES-Webdienst gesendet. HTTPS zur Validierung. Der Dienst überprüft dann diese Anmeldeinformationen anhand der Active Directory um die Identität des Benutzers zu bestätigen, bevor der Zugriff auf Registrierungsrichtlinien oder Zertifikatsregistrierungsfunktionen gewährt wird.

Im Folgenden finden Sie eine schrittweise Aufschlüsselung der Funktionsweise der Benutzername/Passwort-Authentifizierung.

• Der Kunde nimmt Benutzername und Passwort entgegen und Base64-kodiert sie im Format Benutzername:Passwort
• Die kodierten Anmeldeinformationen werden in der HTTP-Basisauthentifizierungs-Header
• Die gesamte Anfrage durchläuft über HTTPS; TLS ist der einzige Schutz für die Anmeldeinformationen. Während der Übertragung. Wichtiger Punkt: Base64 ist eine Kodierung, keine Verschlüsselung. Ohne HTTPS sind die Zugangsdaten vollständig ungeschützt.
• CEP extrahiert und dekodiert den Authorization-Header. Anschließend werden Benutzername und Passwort zur Validierung per LDAP-Bindung an Active Directory übergeben.
• AD-Prüfungen:
  1. Ist das Konto gültig und aktiv?
  2. Ist das Passwort korrekt?
  3. Ist das Konto entsperrt und nicht abgelaufen?
• Schlägt die Überprüfung von Benutzername und Passwort fehl, lehnt CEP die Anfrage sofort ab und gibt eine Fehlermeldung zurück. HTTP 401 Nicht autorisiert Antwort, was bedeutet, dass der Kunde nicht fortfahren darf.
• Wenn die Authentifizierung erfolgreich ist, akzeptiert CEP die Identität, wertet aus, welche Zertifikatregistrierungsrichtlinie für diesen Benutzer oder Rechner gilt, und sendet dann die Details der Registrierungsrichtlinie an den Client zurück.
• Wenn der Client die Zertifikatsanforderung (CSR) an CES sendet, muss er seine Anmeldeinformationen erneut angeben, da CES die zuvor von CEP durchgeführte Authentifizierung weder übernimmt noch darauf zurückgreift.
• CES führt seine unabhängige Validierung anhand von Active Directory unter Verwendung desselben Benutzername/Passwort-Authentifizierungsverfahrens durch.
• Sobald die Identität bestätigt ist, geht CES noch einen Schritt weiter und prüft, ob dieser Benutzer oder diese Maschine über Einschreiben Genehmigung für die angeforderte Zertifikatvorlage und ob die Anfrage selbst den Anforderungen der Vorlage entspricht, wie z. B. dem korrekten Subjektformat oder der zulässigen Kryptografie.
• Schlägt eine dieser Prüfungen fehl, lehnt CES die Anfrage ab. Sind sie erfolgreich, akzeptiert CES die Anfrage und leitet sie im Namen des Kunden an die Zertifizierungsstelle weiter.

Diese Methode ist flexibler für Remote-Benutzer, internetbasierte Systeme, Partnergeräte und nicht in die Domäne eingebundene RechnerEs ist jedoch auch weniger sicher als Kerberos, da es direkt auf Passwörtern basiert. Obwohl die Anmeldeinformationen während der Übertragung durch TLS geschützt sind, hängt die Sicherheit weiterhin von starken Passwortpraktiken, sicherer Endpunktbehandlung und sorgfältiger IIS-Konfiguration ab. Vereinfacht gesagt ist die Benutzername/Passwort-Authentifizierung der praktische Ausweichweg für CEP/CES, wenn Kerberos nicht verwendet werden kann. Sie erfordert jedoch mehr Vorsicht, da sie die direkte Verarbeitung von Anmeldeinformationen in den Zertifikatsregistrierungsprozess einbezieht.

Wann verwendet man Benutzername/Passwort?

Benutzername-/Passwort-Authentifizierung für CEP und CES bereitstellen, wenn:

• Kunden einschreiben sind nicht in eine Domäne eingebunden — Arbeitsgruppenmaschinen, Geräte von Auftragnehmern, IoT-Endpunkte
• Du brauchst waldübergreifend oder organisationsübergreifend Anmeldung ohne Kerberos-Vertrauen
• Kunden Ein Domänencontroller kann nicht zuverlässig erreicht werden. zum Zeitpunkt der Einschreibung
• Sie unterstützen Online-Einschreibung für Fernbedienungen und Mobilgeräte
• Die Bereitstellung ist eine PKIaaS oder verwaltete PKI Szenario für extern verwaltete Kunden
• Sie müssen Unterstützung leisten Nicht-Windows-Plattformen erforderlicher Zertifikatskurs
• Die Kerberos-Infrastruktur ist nicht verfügbar oder unpraktisch in der Zielumgebung

Zertifikatsbasierte Authentifizierung: Die dritte Option zur Verlängerung

Die zertifikatsbasierte Authentifizierung ist die dritte verfügbare Authentifizierungsoption. CESund es wird hauptsächlich verwendet für ZertifikatserneuerungDiese Methode ist nicht für die erstmalige Registrierung geeignet. Bei dieser Methode authentifiziert sich der Client nicht mit Kerberos oder einem Benutzernamen und Passwort. Stattdessen weist er seine Identität durch die Vorlage seiner Zugangsdaten nach. vorhandenes gültiges Zertifikat Das Zertifikat wird während des Verlängerungsantrags an CES übermittelt. CES prüft das Zertifikat anschließend auf Vertrauenswürdigkeit, Gültigkeit, Zugehörigkeit zu einer vertrauenswürdigen Zertifizierungsstelle und Übereinstimmung mit der Identität des Antragstellers. Besteht das Zertifikat die Validierung, akzeptiert CES es als Identitätsnachweis und die Verlängerungsanfrage kann fortgesetzt werden.

Dieser Ansatz ist nützlich, da er das Senden von Passwörtern vermeidet und nicht von einer Kerberos-Verbindung des Clients zu einem Domänencontroller abhängt. Er ist besonders wertvoll für entfernte oder nicht mit der Domäne verbundene Systeme, die bereits über ein Zertifikat verfügen und dieses lediglich erneuern müssen. Allerdings ist diese Methode im Allgemeinen eingeschränkt auf Erneuerungsszenarien Denn der Client muss bereits über ein gültiges Zertifikat verfügen, um sich überhaupt erst authentifizieren zu können. Vereinfacht ausgedrückt: Bei der zertifikatsbasierten Authentifizierung dient das vorhandene Zertifikat als Identitätsnachweis des Clients, wodurch sie eine sichere und effiziente Option zur Zertifikatserneuerung über CES darstellt.

Hinweis: Die automatische Registrierung mittels CEP und CES funktioniert reibungslos, wenn die PKI lokal bereitgestellt und vollständig in Active Directory integriert ist. Wird die PKI jedoch als verwalteter Dienst bereitgestellt und befindet sich die Zertifizierungsstelle außerhalb des Unternehmensnetzwerks, stellt sich die Frage: Wie können sich Geräte sicher für Zertifikate von einer Zertifizierungsstelle registrieren, auf die sie keinen direkten Zugriff haben?

Hauptfunktionen der PKIaaS

• Nahtlose AD-Integration: Das Registrierungsgateway integriert sich in Ihre bestehende Active Directory-Infrastruktur. Ihre Gruppenrichtlinienkonfiguration für die automatische Registrierung verweist auf den Gateway-Endpunkt anstatt auf eine lokale CES-URL. Domänengebundene Computer werden weiterhin per Kerberos-Authentifizierung registriert; für die Endpunkte ändert sich nichts.
• Unterstützung für Geräte außerhalb der Domäne und Remote-Geräte: Das Registrierungsgateway unterstützt die Benutzername/Passwort-Authentifizierung für Geräte, die nicht in eine Domäne eingebunden sind, Remote-Endpunkte, Cloud-Workloads und alle Geräte, die Kerberos nicht verwenden können. Dadurch erhalten Sie ein einziges Registrierungsgateway für Ihre gesamte Geräteflotte – sowohl für Geräte in der Domäne als auch für Geräte außerhalb der Domäne.
• Keine Gefährdung der CA-Infrastruktur: Da das Anmeldeportal als Vermittler fungiert, Ihre Geräte kommunizieren niemals direkt mit der Infrastruktur der Encryption Consulting CA. Die Zertifizierungsstelle (CA) bleibt vollständig durch die Authentifizierungs- und Autorisierungsschicht des Gateways geschützt. Dies entspricht dem Prinzip der vollständigen Datensicherheit, das CES architektonisch sicher macht, und wird nun in einer vollständig verwalteten PKIaaS-Umgebung angewendet.
• Transparenz des Zertifikatslebenszyklus: Jede Registrierungstransaktion über das Encryption Consulting Enrollment Gateway wird protokolliert, nachverfolgt und in die Zertifikatslebenszyklusverwaltung eingespeist. Sie erhalten Einblick in jedes ausgestellte Zertifikat, jede verarbeitete Verlängerung und jeden Registrierungsfehler, ohne die Infrastruktur selbst betreiben zu müssen.
• Skalierbarkeit ohne Kapazitätsplanung: Egal ob Sie Zertifikate für 500 oder 500,000 Geräte registrieren, das Enrollment Gateway skaliert flexibel mit dem Bedarf, ohne dass Ihr Team eine Registrierungsinfrastruktur bereitstellen, dimensionieren oder verwalten muss.
• Compliance-fähiges Audit-Trail: Jede Registrierungstransaktion wird vollständig protokolliert und enthält Informationen zur Auditierbarkeit, zur Identität des Anfragenden, zur Authentifizierungsmethode, zur verwendeten Vorlage, zur Antwort der Zertifizierungsstelle, zum Zeitstempel und zum Ergebnis. Dies unterstützt die PKI-bezogenen Compliance-Anforderungen verschiedener Frameworks, einschließlich … SOC 2ISO 27001, FedRAMP, HIPAA und PCI DSS.

Der Business Case: Eigenentwicklung vs. EC PKIaaS mit Enrollment Gateway

Berücksichtigung	DIY CEP/CES Vor-Ort-Lösungen	Verschlüsselungsberatung PKIaaS + Registrierungsgateway
Interne PKI-Kenntnisse erforderlich	Hohe Anforderungen, erfordert fundierte Kenntnisse in AD CS und PKI.	Die von Encryption Consulting bereitgestellten Fachkenntnisse sind minimal.
CA Infrastrukturmanagement	Verwaltet vom internen Team	Vollständig verwaltet von Encryption Consulting
HSM-Verwaltung	Ihre Hardware, Ihre Schlüsselzeremonien	Verwaltet von Encryption Consulting
Zertifikatvorlagenpflege	Manuell und oft übersehen	Verwaltet und regelmäßig überprüft
Automatische Registrierung für Remote-Geräte	Komplexe CEP/CES-Einrichtung erforderlich	Integriert über das Registrierungsportal
Transparenz des Zertifikatslebenszyklus	Manuelle Nachverfolgung oder Tools von Drittanbietern sind erforderlich.	Die PKIaaS-Plattform ist in dieser Plattform enthalten.
Compliance-Dokumentation	Intern erstellt und gepflegt	Bereitgestellt und gewartet von Encryption Consulting
Skalierung	Erfordert zusätzliche Investitionen in die Infrastruktur.	Elastisch und skaliert automatisch
Algorithmenmigration (z. B. von RSA zu PQC)	Manuelle Aktualisierungen von Vorlagen und CA	Proaktiv gemanagt
Einheitliche Verantwortlichkeit	Verteilt auf verschiedene IT-Teams	Zentralisiert, im Besitz von Encryption Consulting

Wie kann Verschlüsselungsberatung helfen?

Mit fundierter praktischer Expertise in den Bereichen Enterprise-PKI-Design, HSM-Management, Automatisierung des Zertifikatslebenszyklus und Compliance-Frameworks hat Encryption Consulting PKI-Umgebungen für Organisationen vom Mittelstand bis hin zu großen regulierten Branchen, darunter Finanzen, Gesundheitswesen und Regierung, aufgebaut und verwaltet.

Hier kommt Encryption Consulting ins Spiel. PKIaaS Das Angebot geht auf die spezifische technische Herausforderung ein. Genau diese Lücke schließt das Angebot. Verschlüsselungsberatung PKIaaS-Registrierungsportal füllt.

Das Verschlüsselungsberatung PKIaaS-Registrierungsportal ist ein speziell entwickelter Registrierungsbroker-Dienst, der als authentifizierter Vermittler zwischen Ihren registrierten Geräten und der von Encryption Consulting verwalteten CA-Infrastruktur fungiert. Er übernimmt die Registrierungsvermittlung, indem er Zertifikatsanfragen von Ihren Geräten entgegennimmt, diese authentifiziert und in Ihrem Namen an die zuständige Zertifizierungsstelle weiterleitet.

Man kann es sich als Übersetzungsschicht für die Registrierung zwischen Ihrer bestehenden Active Directory- und Gruppenrichtlinien-Auto-Registrierungsinfrastruktur und der extern verwalteten PKIaaS-CA vorstellen, ohne dass Sie Ihre bestehenden Registrierungs-Workflows ersetzen oder neu gestalten müssen.

Für Ihre Geräte und Ihr IT-Team funktioniert die Registrierung genau wie immer. Domänengebundene Geräte registrieren sich automatisch per Gruppenrichtlinie. Geräte außerhalb der Domäne registrieren sich mit der konfigurierten Methode. Zertifikate werden automatisch in den richtigen Zertifikatsspeichern abgelegt. Verlängerungen erfolgen im Hintergrund vor Ablauf der Gültigkeitsdauer.

Im Hintergrund kümmert sich das Anmeldeportal um die gesamte Komplexität. — Weiterleitung von Anfragen an die korrekte, von Encryption Consulting verwaltete ausstellende Zertifizierungsstelle, Durchsetzung der Authentifizierungs- und Autorisierungsrichtlinien, Rückgabe der Ergebnisse an die Clients und Einspeisung von Telemetriedaten zurück in das System Zertifikatslebenszyklusverwaltung Plattform.

Fazit

CEP und CES sind unverzichtbare Bestandteile jeder modernen Unternehmens-PKI und keine optionalen. Jedes Unternehmen betreibt heutzutage Geräte außerhalb des Firmennetzwerks, und ohne CEP und CES ist die automatische Zertifikatsregistrierung für diese Systeme schlichtweg nicht möglich.

In Domänenumgebungen gilt Kerberos weiterhin als Goldstandard für die Authentifizierung. Es bietet sicheren, nahtlosen Zugriff ohne Offenlegung von Anmeldeinformationen, unterstützt gegenseitige Authentifizierung, Maschinenidentitäten und die vollständige automatische Registrierung per Gruppenrichtlinie. Für in die Domäne eingebundene Geräte gibt es keinen praktischen oder sicherheitsrelevanten Grund, eine Alternative zu verwenden. Gleichzeitig spielt die Benutzername/Passwort-Authentifizierung eine wichtige und legitime Rolle in Szenarien, in denen Kerberos nicht eingesetzt werden kann, wie z. B. bei Geräten außerhalb der Domäne oder beim Zugriff über Gesamtstrukturgrenzen hinweg. PKIaaS Umgebungen oder internetbasierte Registrierung. Der richtige Ansatz besteht nicht darin, dies zu vermeiden, sondern es sicher mit starken Kontrollmechanismen wie dedizierten Konten mit geringen Berechtigungen, erzwungenem TLS, Web Application Firewall-Schutz und angemessener Überwachung zu implementieren.

Die Einrichtung einer Zertifizierungsstelle (CA) mag zwar unkompliziert sein, doch der Betrieb einer PKI im großen Maßstab, das Lebenszyklusmanagement, die Einhaltung von Vorschriften, Algorithmusübergänge und die nahtlose Registrierung auf allen Gerätetypen erfordern fortlaufendes Fachwissen, dessen Bereitstellung viele Unternehmen nicht rechtfertigen können. Die PKIaaS- und Enrollment-Gateway-Lösung von Encryption Consulting bietet hierfür eine Lösung: Sie liefert eine PKI auf Enterprise-Niveau mit minimalem Betriebsaufwand, gewährleistet die automatische Zertifikatserneuerung, sorgt für hohe Systemverfügbarkeit und macht dedizierte PKI-Spezialisten überflüssig.