ADCS Open Protocols Spezifikationen: Ein vollständiger technischer Leitfaden

Active Directory Certificate Services (ADCS) ist eines der am weitesten verbreiteten Systeme. Infrastruktur öffentlicher Schlüssel PKI-Lösungen in Unternehmen. Während die meisten Organisationen über die Windows-Benutzeroberfläche oder PowerShell mit ADCS interagieren, liegt die eigentliche technische Komplexität in der Protokollschicht, die den veröffentlichten Open Specifications von Microsoft zugrunde liegt. Das Verständnis dieser Protokolle ist entscheidend für Architekten, Sicherheitsingenieure, Entwickler von PKI-integrierten Tools und Sicherheitsexperten, die Schwachstellen in der Zertifikatsinfrastruktur analysieren.

Dieser Leitfaden bietet eine umfassende, praxisorientierte Aufschlüsselung aller wichtigen ADCS Open Protocol-Spezifikationen, ihrer Zusammenhänge zueinander und ihrer Bedeutung für Ihre PKI-Sicherheitslage.

Was sind Microsoft Open Specifications?

Im Jahr 2008 brachte Microsoft das Offene Spezifikationen Das Programm ist eine öffentlich zugängliche Dokumentationsbibliothek mit detaillierten technischen Spezifikationen für Windows-Protokolle und -Erweiterungen. Ziel war es, Drittanbietern die Entwicklung von Clients und Servern zu ermöglichen, die vollständig mit Microsoft-Produkten interoperabel sind.

Die Open Specifications Library enthält Hunderte von Dokumenten zu Windows-Protokollen, Microsoft Office-Erweiterungen und vielem mehr. Insbesondere für ADCS stellen diese Dokumente die maßgeblichste und am aktivsten gepflegte technische Referenz dar und ersetzen in vielen Fällen ältere TechNet-Inhalte, die im Zuge der Umstellung von Microsoft auf ein einheitliches Dokumentationsportal um 2015/2016 als veraltet galten.

Die ADCS-Open-Protokolllandschaft

Das MS-CERSOD Das Dokument (Übersicht der Zertifikatsdiensteprotokolle) dient als Masterindex für alle ADCS-bezogenen Protokollspezifikationen. Es gliedert die ADCS-Funktionalität in zwei verschiedene Gruppen:

• Zertifikatsregistrierungsverfahren: Wie Kunden Zertifikate anfordern, erhalten und verlängern
• CA-Verwaltungsprotokolle: Wie Administratoren die CA verwalten und betreiben

Zertifikatsregistrierungsprotokolle

1. MS-WCCE – Windows Client Certificate Enrollment Protocol

MS-WCCE ist das grundlegende ADCS-Registrierungsprotokoll und das am tiefsten in Domänen-Windows-Umgebungen integrierte Protokoll. Es definiert eine Reihe von DCOM-Schnittstellen (Distributed Component Object Model), die es einem Client ermöglichen, direkt mit einem ADCS-Server zu kommunizieren. Zertifizierungsstelle zu:

• Neue X.509-Zertifikate anfordern
• Bestehende Zertifikate erneuern
• CA-Eigenschaften und -Fähigkeiten abrufen
• Informationen zum Widerrufsstatus einholen

Kernarchitektur

MS-WCCE basiert auf zwei aufeinanderfolgenden DCOM-Schnittstellen: ICertRequestD und ICertRequestD2. Diese Schnittstellen stellen ein einfaches Anfrage-Antwort-Modell bereit. Der Client sendet eine Zertifikatsanforderung (im PKCS #10-, CMC- oder PKCS #7-Format), und die Zertifizierungsstelle antwortet entweder mit einem signierten Zertifikat oder einer detaillierten Begründung, warum die Anforderung abgelehnt oder in den Status „Ausstehend“ versetzt wurde.

Transport

MS-WCCE verwendet RPC/DCOM über TCP. Dies erfordert eine Netzwerkverbindung zur Zertifizierungsstelle über dynamische RPC-Ports und ist an die Mitgliedschaft in einer Active Directory-Domäne gebunden. Der Richtlinienserver in einem MS-WCCE-Registrierungsszenario ist immer ein Domänencontroller.

Sicherheitsrelevanz

Da MS-WCCE DCOM und Active Directory nutzt, stellt es eine Angriffsfläche für verschiedene bekannte Techniken zur Rechteausweitung durch Enterprise Security Certificates (ESC) dar. Fehlkonfigurationen in Zertifikatvorlagen (Vorlagen-ACLs, EKU-Einstellungen, Berechtigungen des Registrierungsagenten) können es Angreifern ermöglichen, den MS-WCCE-Ablauf zu missbrauchen, um Zertifikate für hochprivilegierte Konten zu erlangen.

2. MS-ICPR -ICertPassage Remote Protocol

MS-ICPR Es ist eng mit MS-WCCE verwandt und verwendet ebenfalls DCOM/RPC. Es stellt die ICertPassage-Schnittstelle bereit, eine einfachere, niedrigere Schnittstelle zur direkten Übermittlung von Zertifikatsanforderungen an eine Zertifizierungsstelle, die jedoch nicht über die in MS-WCCE integrierten, umfangreicheren Registrierungsfunktionen verfügt.

MS-ICPR wird primär in Szenarien mit programmatischen Zertifikatsanforderungen verwendet und stellt einen separaten DCOM-Endpunkt auf der Zertifizierungsstelle dar. Es ist auch in Szenarien mit Zertifikatsweiterleitungsangriffen (wie ESC8 und verwandten Techniken) relevant, da es einen authentifizierten Kanal zur Anforderung von Zertifikaten bereitstellt.

3. MS-XCEP -X.509 Zertifikatsregistrierungsrichtlinienprotokoll

MS-XCEP ist das Protokoll, das die Webdienst für Zertifikatregistrierungsrichtlinien Die Rolle des Zertifikatregistrierungsanbieters (CEP) in ADCS ermöglicht es Clients, Informationen zur Zertifikatregistrierungsrichtlinie über HTTP/HTTPS mittels SOAP-basierter Nachrichtenübermittlung abzurufen – ohne dass eine direkte DCOM-Verbindung zur Zertifizierungsstelle erforderlich ist.

So funktioniert es

Der Client sendet eine GetPolicies-Anfrage an den CEP-Endpunkt. Der Server antwortet mit einer GetPoliciesResponse, die Folgendes enthält: eine Sammlung von Zertifikatregistrierungsrichtlinienobjekten, die verfügbare Zertifikatvorlagen beschreiben, eine Liste der Zertifikatsaussteller (CES-Server), die der Client für jede Vorlage kontaktieren soll, und die Authentifizierungsmethode, die für jeden Aussteller verwendet werden soll (Kerberos, Benutzername/Passwort oder Zertifikat).

Authentifizierungsoptionen

• Kerberos (für in die Domäne eingebundene Geräte)
• Benutzername/Passwort (für Geräte außerhalb der Domäne, die sich mit Domänenanmeldeinformationen authentifizieren)
• CA-Eigenschaften und -Fähigkeiten abrufen

4. MS-WSTEP – Web Services Trust Enrollment Protocol

Wo MS-XCEP die Richtlinien verwaltet EntdeckungMS-WSTEP übernimmt die eigentliche Zertifikatsausstellung. Es ist die Grundlage für die Zertifikatregistrierungs-Webdienst Die Rolle von CES in ADCS. Zusammen bilden MS-XCEP und MS-WSTEP den webdienstbasierten Registrierungsstack, der den von MS-WCCE verwendeten RPC/DCOM-Stack ergänzt und in vielen Szenarien ersetzt.

Protokollmerkmale

• Basierend auf WS-Trust (einem WS-*-Sicherheitsstandard), erweitert um Microsoft-spezifische Funktionen
• Kommuniziert über HTTPS mittels SOAP-Nachrichten
• Unterstützt Zertifikatsanforderungen im PKCS #10- und CMC-Format
• Ermöglicht die durchgängige verschlüsselte Zertifikatsregistrierung ohne Offenlegung des RPC-Ports.

Gängige Bereitstellungsszenarien

Szenario	Verwendetes Protokoll	Transport	Rollendienst
Domäneneingebundener Windows-Client (lokal)	MS-WCCE oder MS-XCEP + MS-WSTEP	RPC/DCOM oder HTTPS	CA / CES
Nicht-Domänengerät mit Domänenanmeldeinformationen	MS-XCEP + MS-WSTEP	HTTPS/SOAP	CEP + CES
Zertifikatserneuerung über das Internet	MS-XCEP + MS-WSTEP (zertifikatbasierte Authentifizierung)	HTTPS/SOAP	CEP + CES
Netzwerkgeräteregistrierung (NDES)	SCEP über HTTP/HTTPS	HTTP / HTTPS	Nahtoderfahrungen
Browserbasierte Registrierung	CAWE (CA-Webregistrierung)	HTTPS	CA Web-Registrierung

Sicherheitshinweis

Der Web-Services-Stack (MS-XCEP + MS-WSTEP) wird üblicherweise im Internet oder in der DMZ eingesetzt. Eine angemessene Authentifizierungshärtung, TLS-Konfiguration und Netzwerksegmentierung sind unerlässlich. Relay-Angriffe im ESC8-Stil können auch HTTP-basierte CES-Endpunkte angreifen, wenn diese nicht für HTTPS und erweiterten Schutz für die Authentifizierung (EPA) konfiguriert sind.

5. MS-CAESO – Protokoll zur automatischen Zertifikatsregistrierung (Archiviert)

MS-CAESO Das ursprüngliche Protokoll regelte die automatische Zertifikatsregistrierung in Windows-Umgebungen – die automatische Registrierung und Erneuerung von Zertifikaten für Domänenbenutzer und -computer basierend auf Gruppenrichtlinien. Diese Spezifikation wurde archiviert, da ihre Kernfunktionalität in die Spezifikationen MS-WCCE und MS-XCEP/MS-WSTEP integriert wurde.

Kenntnisse über MS-CAESO sind nach wie vor wertvoll für Organisationen, die ältere Windows-Umgebungen betreiben oder Legacy-PKI-Konfigurationen prüfen.

Zertifikatvorlage und Richtlinienspezifikationen

6. MS-CRTD – Beschreibung der Zertifikatvorlagen

Zertifikatvorlagen sind das Herzstück von ADCS-Implementierungen in Unternehmen. Sie definieren, welche Zertifikate ausgestellt werden können, an wen, unter welchen Bedingungen und mit welchen Schlüsselverwendungserweiterungen. MS-CRTD legt die genaue Struktur, die Attribute und die Kodierung von Zertifikatvorlagenobjekten fest, wie sie in Active Directory gespeichert sind.

Was MS-CRTD abdeckt

• Das Schema von Zertifikatvorlagenobjekten in Active Directory (Objektklasse, Attributnamen, OIDs)
• Die Kodierung von Richtlinien zur erweiterten Schlüsselverwendung (EKU) in Vorlagen
• Ausstellungsrichtlinien, Einstellungen für Subjektnamen, Registrierungsberechtigungen und Sicherheitsbeschreibungen
• Unterschiede im Vorlagenschema von Version 1, Version 2 und Version 3
• Die Beziehung zwischen Vorlagenattributen und den resultierenden Zertifikatsfeldern

Warum dies für die Sicherheit wichtig ist

Das Verständnis von MS-CRTD ist grundlegend für die Überprüfung von Fehlkonfigurationen von Zertifikatvorlagen – der Hauptursache der meisten ADCS-bezogenen Privilegienausweitungsangriffe (ESC1 bis ESC15). Die kürzlich aufgedeckte ESC15-Schwachstelle (CVE-2024-49019) insbesondere die Ausnutzung des Verhaltens von Schemavorlagen der Version 1, was unterstreicht, warum fundierte Kenntnisse von MS-CRTD eine Sicherheitsvoraussetzung sind.

CA-Verwaltungsprotokolle

7. MS-CSRA – Protokoll zur Fernverwaltung von Zertifizierungsdiensten

MS-CSRA Definiert die DCOM-Schnittstellen, die zur Fernverwaltung einer Zertifizierungsstelle verwendet werden. Es ist das Protokoll hinter dem MMC-Snap-In der Zertifizierungsstelle, dem Tool certutil.exe und der programmgesteuerten Verwaltung von Zertifizierungsstellen über Windows-APIs.

Abgedeckte administrative Vorgänge

• Starten und Beenden des CA-Dienstes
• Einsehen, Genehmigen, Ablehnen und Widerrufen ausstehender Zertifikatsanträge
• Verwalten der Zertifikatsperrliste (CRL) und CRL-Verteilungspunkte (CDPs)
• Konfiguration der CA-Eigenschaften (Schlüsselalgorithmen, CRL-Zeitpläne, Überwachungseinstellungen)
• Sichern und Wiederherstellen der CA-Datenbank
• Abfrage der CA-Datenbank nach ausgestellten, ausstehenden, fehlgeschlagenen und widerrufenen Zertifikaten

MS-CSRA stellt mehrere COM-Schnittstellen bereit, darunter ICertAdmin, ICertAdmin2, ICertView, ICertView2 und IEnumCERTVIEWROW. Die Remote-Zertifizierungsstellenverwaltung über MS-CSRA erfordert die Mitgliedschaft in den Rollen „Zertifizierungsstellenadministrator“ oder „Zertifikatsmanager“. Falsch konfigurierte CA-Rollen stellen ein erhebliches Risiko der Rechteausweitung dar.

8. MS-OCSPA – Online-Responder-Verwaltungsprotokoll

Das Online-Zertifikatstatusprotokoll Der OCSP-Responder ist eine Schlüsselkomponente moderner PKI-Infrastrukturen. Anstatt von Clients das Herunterladen und Parsen großer CRL-Dateien zu verlangen, ermöglicht OCSP die Echtzeitprüfung von Zertifikatssperrungen mit einem einfachen Anfrage-Antwort-Mechanismus.

MS-OCSPA definiert die DCOM-Schnittstellen, die zur Verwaltung des Microsoft OCSP-Responders (der Online Responder-Rollendienst in ADCS) verwendet werden, einschließlich der Konfiguration von OCSP-Widerrufsanbietern, der Verwaltung von OCSP-Signaturzertifikaten und deren automatischer Erneuerung, der Überwachung des Zustands und des Cache-Status des OCSP-Responders sowie der Konfiguration von Aktualisierungsintervallen für Widerrufsdaten.

Operative Best Practices

• OCSP-Responder sollten mit dedizierten, kurzlebigen Signaturzertifikaten (nicht dem CA-Zertifikat selbst) konfiguriert werden.
• OCSP-Heften sollte auf Webservern aktiviert werden, um den OCSP-Datenverkehr zu reduzieren und die Leistung zu verbessern.
• Mehrere OCSP-Responder hinter einem Load Balancer verbessern die Verfügbarkeit und eliminieren Single Points of Failure.

ADCS-Registrierung jenseits offener Spezifikationen: NDES/SCEP und moderne Protokolle

Während die Microsoft Open Specifications die nativen Windows-Registrierungsprotokolle abdecken, unterstützt ADCS auch die Registrierung über Einfaches Zertifikatsregistrierungsprotokoll (SCEP) über die Rolle des Netzwerkgeräte-Registrierungsdienstes (NDES).

NDES und SCEP

Das SCEP ermöglicht Netzwerkgeräten – Routern, Switches, VPN-Gateways und IoT-Geräten –, die nicht in eine Windows-Domäne eingebunden sind, Zertifikate von einer ADCS-Zertifizierungsstelle anzufordern. NDES fungiert als Registrierungsstelle zwischen Gerät und Zertifizierungsstelle und validiert Registrierungsanfragen mithilfe eines Challenge-Password-Mechanismus. SCEP ist in einem IETF-Standard (RFC 8894) definiert und wird von Netzwerkgeräteherstellern und MDM-Plattformen weitgehend unterstützt.

Was ADCS nicht nativ unterstützt

ACME (RFC 8555): ADCS implementiert das ACME-Protokoll nicht nativ. ACME ist der von Let's Encrypt verwendete Standard und wird zunehmend für moderne DevOps- und Cloud-native Umgebungen benötigt. Drittanbieterlösungen können ADCS mit ACME-kompatiblen Clients verbinden.

EST (RFC 7030): Wird in ADCS nicht nativ unterstützt; EST ist eine modernere Alternative zu SCEP für ressourcenbeschränkte Geräte und wird zunehmend zusammen mit IoT-PKI-Programmen eingesetzt.

REST/JSON-API: ADCS stellt keine native REST-API bereit. Die Interaktion erfolgt über DCOM, SOAP oder die COM-Schnittstellen CryptoAPI/CertEnroll.

Sicherheitsimplikationen offener ADCS-Protokolle

Kenntnisse der ADCS-Protokollschicht sind mittlerweile eine Grundvoraussetzung für die IT-Sicherheit und nicht mehr nur ein Anliegen von Entwicklern. ESC-Schwachstellen sind in das allgemeine Sicherheitsbewusstsein gerückt; ESC1, ESC2, ESC3, ESC6, ESC8 und ESC15 sind dokumentiert und werden ausgenutzt. Die folgende Tabelle ordnet jede Schwachstelle ihrer jeweiligen Protokollschicht zu.

Verwundbarkeit	Protokollschicht	Ursache	Notizen
ESC1	MS-WCCE + MS-CRTD	Die Vorlage ermöglicht es dem Anfragenden, einen beliebigen Subjektnamen anzugeben.	Hohe Wirkung; weit verbreitet
ESC2	MS-WCCE + MS-CRTD	Die Vorlage hat eine EKU-Beschränkung für beliebige Zwecke oder keine EKU-Beschränkung.	Hohes Missbrauchspotenzial von Zertifikaten
ESC3	MS-WCCE + MS-CRTD	Missbrauch von Registrierungsagenten über den Zertifikatsanforderungsagenten EKU	Zweistufige Angriffskette
ESC6	MS-WCCE	Das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 wurde auf der CA aktiviert.	CA-Level-Flag, nicht Template-Level
ESC8	MS-WSTEP / HTTP CES	NTLM-Relay an HTTP-basierten CES-Endpunkt	Relay-Angriff; erfordert HTTP (nicht HTTPS)
ESC15	MS-CRTD (V1-Vorlagen)	Beliebige Anwendungsrichtlinieneinfügung in V1-Schemavorlagen	CVE-2024-49019; Patch erforderlich

Praktische Anleitung: Verwendung offener Spezifikationen in Ihrem PKI-Programm

Für PKI-Architekten

• Nutzen Sie MS-CERSOD als maßgebliche Referenz für die Entwicklung von Architekturen zur Einschreibung, insbesondere in Hybride wolke oder internetbasierte Szenarien
• Verwenden Sie MS-XCEP + MS-WSTEP, um Registrierungsabläufe für Geräte außerhalb der Domäne, Cloud-Workloads und Remote-Benutzer zu entwerfen.
• Beachten Sie MS-CRTD beim Entwerfen neuer Zertifikatvorlagen, um sicherzustellen, dass die Attributeinstellungen Ihrer beabsichtigten Sicherheitsrichtlinie entsprechen.

Für Sicherheitsingenieure

• Ordnen Sie Ihre ADCS-Konfiguration MS-CRTD zu, um Fehlkonfigurationen von Vorlagenattributen zu identifizieren, die ESC-Bedingungen entsprechen.
• Überprüfen Sie die CA-Rollenzuweisungen anhand von MS-CSRA, um sicherzustellen, dass die CA-Administrationsoberfläche minimal exponiert ist.
• Stellen Sie sicher, dass alle CES-Endpunkte (MS-WSTEP) HTTPS und erweiterten Schutz für die Authentifizierung (EPA) erfordern, um Relay-Angriffe zu verhindern.

Für Entwickler

• Implementieren Sie benutzerdefinierte Registrierungsclients mithilfe der in MS-WCCE und MS-ICPR für Domänenumgebungen definierten DCOM-Schnittstellen.
• Verwenden Sie die MS-XCEP- und MS-WSTEP-SOAP-Schnittstellen für plattformübergreifende oder webbasierte Registrierungsanwendungen.
• Referenz MS-CSRA für die Entwicklung von CA-Überwachungs-, Prüfungs- oder Lebenszyklusmanagement-Tools

Für Compliance- und Audit-Teams

• Die offenen Spezifikationen liefern Nachweise auf Protokollebene für Konformitätsbescheinigungen (FIPS, Common Criteria, FedRAMP) hinsichtlich der Ausstellung und Verwaltung von Zertifikaten.
• Nutzen Sie die MS-CSRA-Funktionen, um ein automatisiertes Zertifikatsinventar und eine Lebenszyklusüberwachung aufzubauen – entscheidend für die Auditbereitschaft.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist spezialisiert auf PKI-Strategie, ADCS-Architektur und Zertifikatslebenszyklusverwaltung Für Unternehmen und Behörden. Ob Sie ADCS zum ersten Mal implementieren, eine bestehende PKI modernisieren, Ihre Zertifikatsinfrastruktur auf ESC-Schwachstellen prüfen oder ADCS in moderne DevOps-Tools integrieren – unser Team bringt in jedes Projekt umfassende Expertise auf Protokollebene ein.

• PKI-Gesundheitsbewertungen: Protokollebene-Audits Ihrer ADCS-Umgebung anhand offener Microsoft-Spezifikationen und Sicherheits-Benchmarks
• ADCS-Architekturdesign: Design des Registrierungs-Stacks (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), Planung der CA-Hierarchie und Verwaltung von Zertifikatvorlagen
• Zertifikatslebenszyklusmanagement: Automatisierte Erkennung, Überwachung und Erneuerung von Zertifikaten im gesamten Unternehmen.
• Sicherheitshärtung: Behebung von ESC-Fehlkonfigurationen, Härtung der CA-Rolle und Optimierung der CRL/OCSP-Infrastruktur.

Fazit

Die Microsoft Open Specifications for ADCS sind weit mehr als nur Entwicklerreferenzmaterial. Sie bilden die maßgebliche technische Grundlage für das Verständnis, wie Zertifikate unternehmensweit angefordert, ausgestellt, verwaltet und widerrufen werden. Wie die Sicherheitslücken im ESC-Netzwerk deutlich gemacht haben, führen Wissenslücken auf Protokollebene direkt zu ausnutzbaren Sicherheitslücken.

Ob Sie eine neue Registrierungsarchitektur entwerfen, eine bestehende CA-Bereitstellung absichern, PKI-integrierte Tools entwickeln oder eine Sicherheitsbewertung durchführen – fundierte Kenntnisse von MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA und verwandten Standards sind heutzutage unerlässlich. Eine gut verwaltete ADCS-Umgebung erfordert mehr als nur die korrekte Konfiguration. Sie setzt ein tiefes Verständnis der Protokolle voraus, die jede Interaktion zwischen Clients, CAs und den von ihnen ausgestellten Zertifikaten regeln. Die Investition in dieses Wissen ist der sicherste Weg, um den Bedrohungen der Zertifikatsinfrastruktur von morgen einen Schritt voraus zu sein.