# AD Certificate Services (AD CS): Aufbau einer Enterprise PKI

TL;DR / Management Summary Eine PKI (Public Key Infrastructure) ist das Fundament für sichere Kommunikation im Unternehmen. Mit AD CS erstellen wir eine eigene Root-CA, die Zertifikate für Webserver, VPN-Zugänge (Artikel 496) und WLAN (Artikel 498) ausstellt. Ein Senior Admin nutzt die Zertifikats-Auto-Registrierung, damit Computer und User ihre Zertifikate automatisch erhalten und erneuern – ganz ohne manuelle CSR-Anträge.

# 1. Einführung & Architektur

Das Vertrauens-Viereck.

Eine PKI besteht aus:

1. Root CA: Die oberste Instanz (oft Offline!). Ihr Zertifikat muss auf allen Clients als “Vertrauenswürdig” hinterlegt sein.
2. Subordinate CA (Issuing CA): Die Instanz, die im Alltag Zertifikate ausstellt.
3. Certificate Templates: Die Baupläne für Zertifikate (z.B. “Webserver”, “User-Auth”).
4. CRL / OCSP: Die Sperrlisten, um ungültige Zertifikate sofort zu erkennen.

# Architektur-Übersicht (Mermaid)

graph TD
    ROOT[Offline Root CA] -->|Signs| SUB[Issuing Sub CA]
    SUB -->|Auto-Enroll| PC[Windows Client]
    SUB -->|Issue| SRV[Web Server / SSL]
    PC -->|Verify via| CRL[CRL / OCSP Distribution Point]
    AD[Active Directory] --- SUB

# 2. Einrichtung & Vorlagen (Templates)

Standardisierung der Sicherheit.

# Schritt 1: Rolle installieren

Install-WindowsFeature -Name AD-Certificate, ADCS-Web-Enrollment -IncludeManagementTools

# Schritt 2: Zertifikatsvorlagen anpassen

Nutzen Sie niemals die “V1” Templates. Duplizieren Sie diese in “V3” oder “V4” Templates.

• Key Length: Mindestens RSA 2048 (besser 4096) oder Elliptic Curve (ECDSA).
• Validity: Halten Sie Zertifikate kurzlebig (1-2 Jahre) und nutzen Sie die Auto-Erneuerung.

# 3. Deep Dive: Auto-Enrollment

Sicherheit ohne Helpdesk-Tickets.

Auto-Enrollment sorgt dafür, dass PCs beim Beitritt zur Domäne sofort ihr Zertifikat erhalten.

1. GPO: Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Richtlinien für öffentliche Schlüssel -> Zertifikatsdienst-Client - automatische Registrierung.
2. Template: In der Vorlage unter “Sicherheit” der Gruppe Domain Computers die Rechte Read, Enroll und Autoenroll geben.

# 4. Day-2 Operations: Lifecycle & Revocation

Wenn der Schlüssel kompromittiert ist.

# CRL (Certificate Revocation List)

Wenn ein Laptop verloren geht, muss das Zertifikat gesperrt werden.

1. In der CA-Konsole -> Ausgestellte Zertifikate -> Rechtsklick -> Widerrufen.
2. Grund wählen (z.B. “Token broken”).
3. Die Sperre wird in der nächsten CRL-Datei veröffentlicht.

# Zertifikats-Monitoring (PowerShell)

# Findet alle Zertifikate im lokalen Store, die in den nächsten 30 Tagen ablaufen
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) }

# 5. Troubleshooting & “War Stories”

Wenn das Schloss rot wird.

# Top 3 Fehlerbilder

1. Symptom: “Diesem Zertifikat wird nicht vertraut” im Browser.

   • Ursache: Das Root-Zertifikat der CA wurde nicht via GPO an die Clients verteilt.
   • Lösung: Export der .cer Datei und Import via GPO in “Vertrauenswürdige Stammzertifizierungsstellen”.

2. Symptom: Auto-Enrollment funktioniert nicht.

   • Ursache: Berechtigungen am Template falsch oder Dienst CertSvc am Client läuft nicht.
   • Tool: certutil -pulse triggert den Sync manuell.

3. Symptom: CDP (CRL Distribution Point) nicht erreichbar.

   • Folge: Clients verweigern die Verbindung (z.B. VPN), da sie die Sperre nicht prüfen können.
   • Lösung: Stellen Sie sicher, dass die Sperrliste via HTTP (nicht nur LDAP!) erreichbar ist.

# “War Story”: Der schweigende CRL-Tod

Ein Admin änderte die IP des Servers, auf dem die HTTP-Sperrliste lag. Das Ergebnis: Drei Tage später (nach Ablauf der gecachten CRL) konnten sich keine User mehr am WLAN oder VPN anmelden. Lehre: Der wichtigste Teil einer PKI ist nicht die CA selbst, sondern die Erreichbarkeit der Sperrinformationen (CDP). Betreiben Sie den CDP-Webserver hochverfügbar auf Proxmox!

# 6. Monitoring & Reporting

Dashboard der Identitäten.

# KPIs für die PKI

• Failed Requests: Wie oft schlagen Zertifikats-Anträge fehl?
• Expiration Alerts: Rechtzeitige Warnung vor Ablauf von Root-Zertifikaten (Kritisch!).

# 7. Fazit & Empfehlung

AD CS ist mächtig, erfordert aber höchste Disziplin.

• Empfehlung: Betreiben Sie Ihre Root CA offline (als VM, die exportiert und gelöscht wird, oder auf einem USB-Stick). Nur die Sub-CA darf online sein.
• Alternative: Für öffentliche Webseiten nutzen Sie weiterhin Let’s Encrypt (Artikel 322). Die interne PKI ist für interne Identitäten (User, PCs, VPN) gedacht.

# Anhang: Cheatsheet

# Referenzen

• Microsoft Learn: AD CS Design Guide
• PKI Solutions: Best Practices for AD CS
• RFC 5280: X.509 Public Key Infrastructure