# Certificate Services & PKI (AD CS)

> Die Active-Directory-PKI als Verteidiger verstehen und sicher betreiben: zweistufige Hierarchie mit Offline-Root, Certificate Templates und Enroll-Rechte, EKU-Wirkung, Herkunft von Subject/SAN, die Fehlkonfig-Klassen ESC1 und ESC8, Härtung, CRL-/Revocation-Abhängigkeit und der Blast-Radius eines kompromittierten CA-Schlüssels.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/certificate-services  
Stand: 2026-07-27  
Interaktiver Teil: 15 Checks (nur im Browser)

## Certificate Services & PKI: Vertrauensanker, Templates, EKU und die ESC-Fehlkonfigurationen

### Wozu eine PKI in AD — und warum sie Tier-0 ist

Active Directory Certificate Services (**AD CS**) ist die interne **Public-Key-Infrastruktur** der Domäne. Sie stellt Zertifikate aus, mit denen sich Nutzer und Maschinen **authentifizieren** (Smartcard-/PKINIT-Logon, `802.1x`, VPN, LDAPS, Code Signing). Ein Zertifikat ist damit ein **zweiter Weg, eine Identität zu beweisen** — neben dem Passwort.

Der entscheidende Punkt für die Sicherheit: Eine **Enterprise-CA** wird beim Setup in den **NTAuth-Store** der Domäne eingetragen. Jedes Zertifikat, das an eine dieser CAs zurückkettet und eine Authentifizierungs-EKU trägt, wird von Domain Controllern als **gültiger Logon-Nachweis** akzeptiert. Wer also unkontrolliert Client-Auth-Zertifikate ausstellen kann, kann sich als beliebige Identität anmelden — ganz ohne deren Passwort.

> **Merksatz:** Eine ausstellende CA ist so mächtig wie ein Passwort-Reset für die **ganze Domäne**. Deshalb ist AD CS **Tier-0** — genau wie Domain Controller. Fehler in der PKI sind keine „Zertifikatsdetails“, sondern Pfade zur Domänenübernahme.

### Zweistufig: Offline-Root und Online-Issuing

Die verbreitete Praxis ist eine **zweistufige Hierarchie**: eine **Root-CA**, die den Vertrauensanker signiert, und darunter eine oder mehrere **Issuing-CAs**, die den Tagesbetrieb erledigen. Der Grund ist Blast-Radius-Kontrolle:

|  |  |
| --- | --- |
| **Root-CA** | Signiert nur die untergeordneten CA-Zertifikate — selten, mit langer Laufzeit. Wird als **standalone** aufgesetzt und danach **offline** gehalten (heruntergefahren/getrennt). Nicht domänengejoint, kein Netz. Ihr privater Schlüssel ist das höchste Gut. |
| **Issuing-CA (Enterprise, online)** | Domänengejoint, stellt die Massenzertifikate für Nutzer/Maschinen aus, kennt Templates und Autoenrollment. Wird sie kompromittiert, kann man sie **widerrufen und über die Root neu ausstellen**, ohne den Vertrauensanker zu verlieren. |

Eine **einstufige** PKI (Root = Issuing, online, domänengejoint) spart Aufwand, koppelt aber den Vertrauensanker an die Angriffsfläche des Tagesbetriebs: Wird diese eine CA kompromittiert, ist der **Anker** selbst verloren — Recovery heißt dann, die gesamte PKI neu aufzubauen und überall neu zu verteilen.

**Kurzcheck:** Warum hält man die Root-CA offline und lässt eine separate Issuing-CA den Betrieb machen?

- [x] Damit eine Kompromittierung der Betriebs-CA widerrufen und über den weiterhin vertrauenswürdigen Anker neu ausgestellt werden kann.
- [ ] Weil eine Offline-Root Zertifikate schneller ausstellt als eine Online-CA.
- [ ] Weil nur eine Offline-Root Zertifikate für Smartcard-Logon ausstellen darf.

> Genau. Die Trennung begrenzt den Blast-Radius: Der seltene, offline gehaltene Schlüssel bleibt geschützt, während die exponierte Issuing-CA ersetzbar bleibt.

### Certificate Templates: die Blaupause der Ausstellung

Eine Enterprise-CA stellt nichts frei Hand aus — sie folgt **Certificate Templates**. Ein Template legt fest: welche **EKU** das Zertifikat trägt, **wer** es beantragen darf, **wer** Subject/SAN liefert und ob ein Mensch die Ausstellung **genehmigen** muss. Wer das Template (bzw. dessen ACL) kontrolliert, kontrolliert damit **was ausgestellt wird**.

|  |  |
| --- | --- |
| **Enroll** | Recht, ein Zertifikat aus diesem Template **aktiv zu beantragen**. Sollte auf die Gruppe begrenzt sein, die es fachlich braucht — nicht `Domain Users` oder `Authenticated Users` für Auth-Templates. |
| **Autoenroll** | Zusätzlich zu Enroll: Clients ziehen das Zertifikat **automatisch und lautlos** per Gruppenrichtlinie. Bequem für Flottenrollout, aber es verteilt ein gefährliches Template ohne jede menschliche Zwischenkontrolle **an die gesamte Zielpopulation**. |
| **Write/FullControl auf das Template** | Wer die Template-**Konfiguration** ändern darf, kann Flags, EKU und Enroll-Rechte **umschreiben** — also ein harmloses Template in ein gefährliches verwandeln. Dieses Recht gehört ausschließlich zu Tier-0-PKI-Administratoren. |

> **Leitfrage:** Für jedes Auth-Template: **Wer darf enrollen, wer darf es ändern — und braucht diese Population wirklich ein Zertifikat, mit dem man sich anmelden kann?** Zu breite Rechte sind die Wurzel fast aller AD-CS-Eskalationen.

### EKU: wofür ein Zertifikat überhaupt gilt

Die **Extended Key Usage (EKU)** ist die Liste der Zwecke, für die ein Zertifikat gültig ist. Sie ist die eigentliche „Vollmacht“ des Zertifikats. Für die Sicherheit zählt vor allem, **ob eine EKU die Authentifizierung gegen AD erlaubt**:

|  |  |
| --- | --- |
| **Client Authentication** (`1.3.6.1.5.5.7.3.2`) | Erlaubt, sich mit dem Zertifikat als Client zu authentifizieren (u. a. PKINIT/Kerberos, LDAPS-Clientauth). Reicht für Identitätsübernahme, wenn der Antragsteller den Namen im Zertifikat bestimmen kann. |
| **Smart Card Logon** (`1.3.6.1.4.1.311.20.2.2`) | Ebenfalls eine **Authentifizierungs-EKU** — für interaktives Smartcard-/PKINIT-Logon. Aus Angreifersicht gleich brisant wie Client Authentication. |
| **Any Purpose / keine EKU** | „Any Purpose“ oder ein fehlendes EKU-Feld (SubCA) machen das Zertifikat für **jeden** Zweck nutzbar — inklusive Auth. Am gefährlichsten, weil unbegrenzt. |
| **Server Authentication, Encrypting File System, …** | Zwecke **ohne** Client-Auth. Ein reines Server-Auth-Zertifikat erlaubt **keine** Anmeldung als Nutzer — die EKU begrenzt die Vollmacht. |

> **Merksatz:** Nicht jedes Zertifikat ist ein Logon-Nachweis. Ob eines zur **Identitätsübernahme** taugt, entscheidet die EKU: Client Authentication, Smart Card Logon, PKINIT oder Any Purpose sind die gefährlichen — reine Server-/Verschlüsselungs-EKUs sind es nicht.

### Wer liefert Subject und SAN?

Ein Auth-Zertifikat sagt: „Ich bin **dieser** Principal.“ Welcher Principal das ist, steht im **Subject** bzw. im **Subject Alternative Name (SAN)** — bei AD-Auth meist der UPN. Entscheidend ist, **wer diesen Namen setzt**:

- **Von der CA aus AD gebaut (Default und sicher):** Die CA setzt Subject/SAN anhand des **authentifizierten Antragstellers** aus dem Verzeichnis. Man kann nur ein Zertifikat für sich selbst bekommen.
- **Vom Antragsteller geliefert (`ENROLLEE_SUPPLIES_SUBJECT`):** Das Template erlaubt, dass der **Antragsteller** Subject/SAN frei angibt (im Template-Dialog „Angabe in der Anforderung“). Damit kann jemand einen **fremden** UPN eintragen — z. B. den eines Domain Admins.

> **Warum das zusammen mit der EKU zählt:** „Antragsteller liefert den Namen“ ist für ein reines Verschlüsselungszertifikat harmlos. In Kombination mit einer **Auth-EKU** wird daraus die Fähigkeit, sich als **beliebige** Identität auszuweisen. Erst die **Kombination** Auth-EKU + antragstellergelieferter SAN + breite Enroll-Rechte ist der Sprengstoff.

**Kurzcheck:** Ein Template hat die Client-Authentication-EKU und erlaubt dem Antragsteller, den SAN selbst zu setzen; Enroll ist für `Domain Users` offen. Was ist das Kernproblem?

- [x] Jeder Domänennutzer kann ein Auth-Zertifikat auf einen fremden Principal (z. B. Domain Admin) ausstellen und sich damit als dieser anmelden.
- [ ] Nichts Kritisches — die CA prüft beim Logon ohnehin das Passwort des Ziel-Accounts.
- [ ] Nur ein Verfügbarkeitsproblem, weil zu viele Nutzer gleichzeitig enrollen.

> Richtig. Auth-EKU plus selbst gelieferter SAN plus breite Enroll-Rechte ergibt Identitätsübernahme — das ist die ESC1-Klasse.

### Fehlkonfig-Klassen: ESC1 und ESC8 als Prinzip

Die bekannten AD-CS-Eskalationen (in der Forschung als **ESCx** nummeriert) sind keine Exploits in einer Software-Version, sondern **Klassen von Fehlkonfigurationen**. Zwei sind das Fundament:

- **ESC1 — antragstellergelieferter SAN auf einem Auth-Template.** Ein Template erfüllt gleichzeitig: (1) niedrig privilegierte Enroll-Rechte, (2) eine **Auth-EKU** (Client Auth / Smart Card Logon / PKINIT / Any Purpose), (3) `ENROLLEE_SUPPLIES_SUBJECT`, (4) **keine** Manager-Genehmigung und (5) keine geforderte autorisierte Signatur. Ergebnis: jeder berechtigte Antragsteller stellt sich ein Zertifikat für einen **beliebigen** Principal aus. Die Abwehr sitzt an **jeder** dieser Bedingungen — am wirksamsten daran, den selbst gelieferten SAN abzuschalten und Auth-EKUs nur an enge Gruppen zu vergeben.
- **ESC8 — NTLM-Relay auf die Web-Enrollment-Endpunkte.** Die HTTP-basierten Enrollment-Schnittstellen (Web Enrollment `certsrv`, Certificate Enrollment Web Service) akzeptieren standardmäßig **NTLM** und sind **nicht** gegen Relay geschützt. Ein Angreifer zwingt ein privilegiertes Maschinenkonto (etwa einen DC) zur Authentifizierung (Coercion) und **relayt** diese an den HTTP-Endpunkt, um ein Zertifikat **für den DC** zu erhalten. Die Abwehr sitzt am Kanal: **Extended Protection for Authentication (EPA/Channel Binding)** erzwingen, **HTTPS** verlangen, **NTLM** unterbinden — oder Web-Enrollment ganz entfernen, wenn ungenutzt.

> **Evergreen-Blick:** Merke dir nicht Tool-Schritte, sondern die **Wurzel**: ESC1 ist zu breite Ausstellungs-Vollmacht (wer + welcher Name + welche EKU); ESC8 ist ein **ungeschützter Auth-Kanal** (HTTP + NTLM ohne Channel Binding). Neue ESC-Nummern variieren die Bausteine — die zwei Prinzipien bleiben.

### Härten, Widerruf und der CA-Schlüssel

**Härten** heißt: die Ausstellungs-Vollmacht auf das Nötige verengen. Die wirksamsten Hebel, grob nach Wirkung:

- `ENROLLEE_SUPPLIES_SUBJECT` auf Auth-Templates **abschalten** (CA baut Subject/SAN aus AD).
- **Enroll-Rechte** kürzen — keine `Domain Users`/`Authenticated Users` auf Auth-Templates; Autoenroll nur, wo bewusst gewollt.
- **Manager-Genehmigung** für sensible Templates erzwingen (menschliches Gate).
- Gefährliche/unnötige **EKUs** entfernen; keine „Any Purpose“-Templates für breite Gruppen.
- **Ungenutzte** Auth-Templates ganz von der CA nehmen (unpublish) — was niemand braucht, ist reine Ausstellungsfläche und wird durch eine spätere Fehländerung zum Pfad.
- Für die HTTP-Enrollment-Endpunkte **EPA + HTTPS** erzwingen und NTLM unterbinden.

**Revocation** ist die Notbremse — aber nur so gut wie ihre Erreichbarkeit. Ein Zertifikat gilt als gültig, solange die prüfende Gegenstelle keinen Widerruf sieht. Ein Widerruf wirkt erst, wenn eine **aktualisierte CRL** (oder OCSP-Antwort) **veröffentlicht** und **erreichbar** ist und die Gegenstelle sie prüft; zwischengespeicherte CRLs gelten bis zu ihrem Ablauf weiter. Wichtig: Der AD-CS-**Online Responder (OCSP)** leitet seine Antwort in der Standardkonfiguration aus **derselben CRL** ab — er ist damit nicht automatisch aktueller als die CRL, nur feiner abrufbar. Kehrseite: Ist der **CRL Distribution Point (CDP) unerreichbar** und prüft die Gegenstelle „hart“, schlägt jede Validierung fehl — ein klassischer, flächiger Ausfall (TLS, Logon), ganz ohne Angreifer.

> **Blast-Radius des CA-Schlüssels:** Wer den **privaten Schlüssel** einer ausstellenden CA stiehlt, schmiedet gültige Zertifikate für **jeden** Principal — die kein CRL-Eintrag stoppt (das gefälschte Zertifikat wurde nie regulär ausgestellt). Ein solcher Diebstahl überlebt sogar einen `krbtgt`-Reset. Deshalb: CA-Schlüssel in ein **HSM** (nicht exportierbar), nicht als exportierbaren Software-Schlüssel. Recovery bei Verdacht = CA-Schlüssel/CA **neu aufsetzen** und Vertrauen neu verteilen.

### Zusammenfassung — gleich im Check

Die Achsen dieses Moduls: **zweistufige Hierarchie** (Offline-Root/Online-Issuing) und die CA als **Tier-0-Vertrauensanker**; **Templates** (Enroll vs. Autoenroll, wer darf ändern); **EKU** (welche Zwecke Auth erlauben); **Herkunft von Subject/SAN**; die Fehlkonfig-Klassen **ESC1** und **ESC8**; **Härtung**, **Revocation/CRL-Abhängigkeit** und der **Blast-Radius des CA-Schlüssels**.

> **Gleich im Check:** Du entscheidest für konkrete Situationen die beste Konfiguration oder Reaktion — und in einer Audit-Mission markierst du in einem verwundbaren Template die Zeilen, die zusammen ESC1 ergeben. Pro Option siehst du, warum sie die Wurzel trifft oder aus welchem benannten Grund nur ein Symptom.

## Quellen

- Microsoft Learn — Active Directory Certificate Services (AD CS) Overview / Design (Two-Tier-Hierarchie, Offline-Root)
- Microsoft Learn — Certificate Templates: Berechtigungen (Enroll/Autoenroll) und Subject-Name-Optionen
- Microsoft Learn — NTAuth-Store und zertifikatbasierte Anmeldung (PKINIT/Smartcard)
- SpecterOps — „Certified Pre-Owned: Abusing Active Directory Certificate Services“ (Schroeder/Christensen): ESC1- und ESC8-Fehlkonfigurationsklassen
- Microsoft Learn — Extended Protection for Authentication (Channel Binding) für Web Enrollment / CES
- Microsoft Learn — NTAuth-Store und zertifikatbasierte Anmeldung
- SpecterOps — „Certified Pre-Owned: Abusing Active Directory Certificate Services“ (CA als Tier-0)
- Microsoft Learn — AD CS Design: Two-Tier-Hierarchie und Offline-Root-CA
- Microsoft Learn — Standalone- vs. Enterprise-CA
- Microsoft Learn — Extended Key Usage und zertifikatbasierte Anmeldung
- SpecterOps — „Certified Pre-Owned“: Authentifizierungs-EKUs als Voraussetzung der Template-Eskalation
- Microsoft Learn — Certificate Templates: Application Policies / Extended Key Usage
- SpecterOps — „Certified Pre-Owned“: Any-Purpose- und fehlende EKUs als Auth-Vektor
- Microsoft Learn — Certificate Templates: Enroll- und Autoenroll-Berechtigungen; Autoenrollment per Gruppenrichtlinie
- SpecterOps — „Certified Pre-Owned“: Enrollment-Rechte als Voraussetzung von Template-Eskalationen
- Microsoft Learn — Certificate Templates: Berechtigungen auf dem Template-Objekt (Write/FullControl)
- SpecterOps — „Certified Pre-Owned“: Kontrolle über Template-Objekte als Eskalationsklasse
- Microsoft Learn — Certificate Templates: Subject Name („Build from AD“ vs. „Supply in the request“ / ENROLLEE_SUPPLIES_SUBJECT)
- SpecterOps — „Certified Pre-Owned“: ESC1 (antragstellergelieferter SAN auf Auth-Template)
- Microsoft Learn — Certificate Templates auf einer Enterprise-CA veröffentlichen und entfernen (Ausstellungsfläche verwalten)
- SpecterOps — „Certified Pre-Owned“: Reduktion der ESC-Angriffsfläche (ungenutzte bzw. gefährliche Templates entfernen)
- SpecterOps — „Certified Pre-Owned: Abusing Active Directory Certificate Services“: ESC1-Bedingungen
- Microsoft Learn — Certificate Templates: Subject Name, Issuance Requirements und Berechtigungen
- SpecterOps — „Certified Pre-Owned“: ESC8 (NTLM-Relay auf AD-CS-Web-Enrollment)
- Microsoft Learn — Extended Protection for Authentication (Channel Binding) und Mitigation von NTLM-Relay auf HTTP-Endpunkte
- SpecterOps — „Certified Pre-Owned“: Priorisierung der ESC-Klassen nach Ausnutzbarkeit
- Microsoft Learn — AD CS Sicherheits- und Härtungsempfehlungen
- Microsoft Learn — CRL Distribution Points (CDP), OCSP und Revocation-Prüfung
- Microsoft Learn — AD CS: Verfügbarkeit der Revocation-Infrastruktur planen
- Microsoft Learn — Certificate Revocation: CRL-Veröffentlichung, Gültigkeitsdauer und manuelles Publizieren
- Microsoft Learn — OCSP-Responder und Abhängigkeit von der CRL
- Microsoft Learn — CA-Schlüsselspeicher: KSP, HSM und Schutz des privaten Schlüssels
- SpecterOps — „Certified Pre-Owned“: Diebstahl des CA-Schlüssels („Golden Certificate“) als Blast-Radius
- SpecterOps — „Certified Pre-Owned“: Kompromittierung des CA-Schlüssels und Golden Certificate
- Microsoft Learn — AD CS: Wiederherstellung/Ersatz einer kompromittierten CA und Vertrauensverwaltung