ADCS: Eigene PKI mit Active Directory Certificate Services aufbauen

Warum eine eigene PKI im KMU ueberhaupt Sinn macht

Sobald du 802.1X fuer WLAN/LAN, IPsec zwischen Servern, Code-Signing fuer interne Skripte, S/MIME fuer E-Mail-Verschluesselung oder einfach nur interne HTTPS-Endpunkte ohne Browser-Warnung brauchst, stoesst du an die Grenzen von selbstsignierten Zertifikaten oder teuren oeffentlichen Zertifikaten pro Host. Eine eigene PKI (Public Key Infrastructure) auf Basis von Active Directory Certificate Services (ADCS) loest das: Du bekommst eine firmeneigene Zertifizierungsstelle, deren Root-Zertifikat automatisch per GPO auf alle domaenengejoined Clients verteilt wird - und ab dann vertrauen Windows, Edge, teilweise auch Firefox/Chrome (ueber den Windows-Zertifikatspeicher) allem, was diese CA ausstellt.

Der Haken: Eine PKI ist kein “Rolle installieren und fertig”-Produkt. Ein falsch konfigurierter Root-CA-Key, eine vergessene CRL-Verlaengerung oder eine zu offene Zertifikatsvorlage kann dazu fuehren, dass jemand ein Domain-Controller-Zertifikat faelscht und sich als DC ausgibt (das ist real passiert, siehe ESC1-ESC8-Angriffsvektoren von SpecterOps). Deshalb bauen wir das hier sauber und mit Sicherheitsbewusstsein auf.

Two-Tier-PKI: Root-CA vs. Issuing-CA

Die Standardarchitektur fuer jede ernstzunehmende PKI - vom KMU bis zum Konzern - ist die zweistufige Hierarchie:

        Offline Root-CA (Standalone, ausgeschaltet)
                    |
                    | signiert einmalig
                    v
        Online Issuing-CA (Enterprise, domain-joined)
                    |
                    | stellt taeglich aus
                    v
   Benutzer-, Computer-, Server-, IPsec-, Code-Signing-Zertifikate

Root-CA (Stammzertifizierungsstelle):

• Wird als Standalone-CA installiert (nicht Enterprise), oft auf einer VM, die nach der Ersteinrichtung heruntergefahren und nur bei Bedarf (CRL-Erneuerung, neue Issuing-CA) gestartet wird.
• Muss NICHT domaenengejoined sein - im Gegenteil, ein Offline-Root sollte idealerweise komplett vom Netz getrennt sein (kein Netzwerkadapter, oder isoliertes Host-only-Netz).
• Signiert nur ein einziges Zertifikat direkt: das der Issuing-CA. Danach passiert fast nichts mehr ausser der periodischen CRL-Signatur.
• Typische Gueltigkeit: 15-20 Jahre.

Issuing-CA (frueher “Subordinate CA”):

• Wird als Enterprise-CA installiert, ist domain-joined und in AD integriert.
• Stellt die eigentlichen Zertifikate an Benutzer, Computer, Server, Netzwerkgeraete aus - taeglich, automatisiert per Auto-Enrollment.
• Nutzt Zertifikatsvorlagen (Templates) aus dem AD-Schema.
• Typische Gueltigkeit des CA-Zertifikats: 10 Jahre, ausgestellte Endzertifikate meist 1-2 Jahre.

Root-CA einrichten (Standalone, offline)

Auf einer isolierten VM (z. B. PKI-ROOT01, kein Domain-Join, idealerweise kein Netzwerkadapter aktiv):

# Feature installieren
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Vor der Konfiguration legst du eine CAPolicy.inf an (steuert Basisrichtlinie, Schluessellaenge und CRL-Verhalten der Root):

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=Weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

Datei nach C:\Windows\CAPolicy.inf kopieren, dann konfigurieren:

Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "Contoso-Root-CA" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 20

Danach das Root-CA-Zertifikat und die erste CRL exportieren, auf einen USB-Stick oder Fileshare kopieren - die brauchst du gleich fuer die Issuing-CA und fuer die GPO-Verteilung.

Issuing-CA einrichten (Enterprise, online)

Auf dem domain-joined Mitgliedsserver (z. B. PKI-SUB01):

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

# Zertifikatsanforderung fuer die Issuing-CA erzeugen (offline signiert werden muss)
Install-AdcsCertificationAuthority `
  -CAType EnterpriseSubordinateCA `
  -CACommonName "Contoso-Issuing-CA-01" `
  -KeyLength 2048 `
  -HashAlgorithmName SHA256

Der Assistent erzeugt eine .req-Datei. Diese transportierst du (offline, per USB-Stick) zur Root-CA, signierst sie dort und installierst die Antwort auf der Issuing-CA:

# Auf der Root-CA: Request signieren
certreq -submit -config "PKI-ROOT01\Contoso-Root-CA" C:\transfer\subca.req C:\transfer\subca.crt

# Auf der Issuing-CA: Zertifikat installieren
certutil -installcert C:\transfer\subca.crt
Start-Service certsvc

Entscheidungstabelle: Welche CA-Architektur fuer welches KMU?

Zertifikatsvorlagen (Certificate Templates)

Zertifikatsvorlagen sind AD-Schema-Objekte, die definieren, WAS ausgestellt wird (Schluessellaenge, Gueltigkeit, Verwendungszweck/EKU, Subject-Name-Quelle) und WER es anfordern darf. Sie leben unter CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=... im Konfigurationscontainer - forestweit sichtbar, nicht domaenengebunden.

Wichtige Vorlagen-Versionen:

• v1: Legacy, nicht editierbar (nur duplizieren), keine Auto-Enrollment-Unterstuetzung.
• v2: Editierbar, Auto-Enrollment moeglich, Mindest-OS Windows Server 2003.
• v3: Unterstuetzt CNG (Cryptography Next Generation), z. B. ECC-Schluessel, ab Server 2008.
• v4: Kombiniert v2/v3-Faehigkeiten, erzwingbar nur bei reinen Server-2012+-Umgebungen, unterstuetzt Schluesselattestierung via TPM.

Praxisbeispiel: Eine eigene Vorlage fuer WLAN-Client-Zertifikate (802.1X) duplizieren und anpassen:

# Vorlagenverwaltung oeffnen
certtmpl.msc

Manuelle Schritte im MMC-Snap-in:

1. Vorlage “Workstation Authentication” rechtsklicken -> Vorlage duplizieren.
2. Reiter “Allgemein”: Anzeigename Contoso-8021X-Client, Gueltigkeit 1 Jahr, Erneuerungszeitraum 6 Wochen.
3. Reiter “Antragstellername”: “Aus Active-Directory-Informationen erstellen” waehlen (NICHT “Im Antrag angegeben” - genau das waere die ESC1-Falle).
4. Reiter “Sicherheit”: Gruppe GG-WLAN-Clients mit Lesen + Registrieren + Automatisch registrieren berechtigen.
5. Reiter “Erweiterungen”: Anwendungsrichtlinien pruefen, dass nur “Client-Authentifizierung” drin ist.
6. OK, dann auf der Issuing-CA unter certsrv.msc -> Zertifikatvorlagen -> Neu -> Auszustellende Zertifikatvorlage -> Contoso-8021X-Client auswaehlen.

Per PowerShell die Vorlage auf der CA veroeffentlichen:

Add-CATemplate -Name "Contoso-8021X-Client" -Force

Auto-Enrollment per GPO

Auto-Enrollment ist das Zusammenspiel aus vier Bausteinen: einer Gruppenrichtlinie, die das Verhalten am Client aktiviert; einer Zertifikatsvorlage mit den passenden Berechtigungen; der Issuing-CA, auf der diese Vorlage veroeffentlicht ist; und dem Client, der bei jeder Anmeldung und alle 8 Stunden per Hintergrundaufgabe prueft, ob etwas Neues benoetigt wird.

GPO-Konfiguration Schritt fuer Schritt

1. Neue GPO erstellen, z. B. PKI - Auto-Enrollment Computer, verknuepft mit der OU, die deine Zielcomputer enthaelt.
2. Pfad im Group Policy Management Editor: Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Richtlinien fuer oeffentliche Schluessel -> Zertifikatdienstclient - Automatische Registrierung
3. Konfigurationsmodell auf Aktiviert setzen.
4. Beide Checkboxen aktivieren: “Abgelaufene Zertifikate erneuern, ausstehende Zertifikate aktualisieren und widerrufene Zertifikate entfernen” sowie “Zertifikate aktualisieren, die Zertifikatvorlagen verwenden”.
5. Fuer Benutzerzertifikate denselben Pfad unter Benutzerkonfiguration wiederholen.

Per PowerShell (falls du GPOs als Code verwaltest):

Set-GPRegistryValue -Name "PKI - Auto-Enrollment Computer" `
  -Key "HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment" `
  -ValueName "AEPolicy" -Type DWord -Value 0x7

(0x7 = alle drei Flags: Auto-Enrollment aktiviert, abgelaufene erneuern, Vorlagen aktualisieren.)

Auf dem Client kannst du den Vorgang manuell antriggern, statt auf den naechsten Reboot/Logon zu warten:

gpupdate /force
certutil -pulse

CRL und OCSP: Wie Sperrpruefung funktioniert

Jeder Client, der ein Zertifikat validiert, muss auch pruefen, ob es zwischenzeitlich gesperrt wurde. Dafuer gibt es zwei Mechanismen:

CRL (Certificate Revocation List): Eine von der CA signierte Liste aller gesperrten Zertifikat-Seriennummern. Der Client laedt die Liste ueber die im Zertifikat hinterlegte CDP-URL (CRL Distribution Point) herunter und prueft lokal. Nachteil: Die Liste kann bei vielen Sperrungen gross werden, und sie ist nur so aktuell wie ihr Veroeffentlichungsintervall.

OCSP (Online Certificate Status Protocol): Der Client fragt live bei einem OCSP-Responder (der ADCS-Rolle “Onlineresponder”) nach dem Status eines einzelnen Zertifikats. Antwort ist klein (ca. 2,5 KB) und aktueller als eine CRL, erfordert aber, dass der Responder erreichbar ist - fuer VPN-lose Aussenstandorte oder Partnerzugriffe ein wichtiger Design-Punkt.

Die URL zum OCSP-Responder steht im AIA-Feld des Zertifikats, die CRL-URL im CDP-Feld. Ein haeufiger Anfaengerfehler: CDP/AIA zeigen nach der Testinstallation nur auf einen internen LDAP-Pfad (ldap:///CN=...) - das funktioniert nur innerhalb des AD-Sites-Netzwerks. Fuer alles ausserhalb (Homeoffice ohne VPN, IoT-Geraete, Partnerfirmen) brauchst du eine per HTTP erreichbare CDP/AIA-URL.

# CDP-URLs konfigurieren (Beispiel: interne + HTTP-oeffentliche URL)
certutil -setreg CA\CRLPublicationURLs `
  "1:C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl\n2:http://pki.contoso.ch/crl/%3%8%9.crl\n2:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"

# CRL-Gueltigkeit setzen: 1 Woche Basis, 1 Tag Delta
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "Days"

Restart-Service certsvc
certutil -crl

Entscheidungshilfe CRL vs. OCSP

Zertifikatserneuerung und Sperrung im Betrieb

Automatische Erneuerung

Solange Auto-Enrollment aktiv ist, erneuert Windows Zertifikate automatisch, sobald der in der Vorlage definierte “Erneuerungszeitraum” (z. B. 6 Wochen vor Ablauf bei einjaehriger Gueltigkeit) erreicht ist - vollkommen ohne Benutzerinteraktion, sofern der Client online ist und die GPO greift.

Manuelle Sperrung eines Zertifikats

Wenn ein Geraet gestohlen wird oder ein privater Schluessel kompromittiert wurde, sperrst du das zugehoerige Zertifikat in der Zertifizierungsstellenkonsole (certsrv.msc) unter “Ausgestellte Zertifikate”, Rechtsklick -> Alle Aufgaben -> Zertifikat widerrufen. Waehle dabei einen sinnvollen Sperrgrund:

Per PowerShell/certutil:

# Zertifikat anhand Seriennummer sperren (Grund 1 = Key Compromise)
certutil -revoke 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d 1

# Neue CRL sofort veroeffentlichen, damit die Sperrung wirksam wird
certutil -crl

CA-Zertifikat selbst erneuern

Faustregel: Die CA erneuern, wenn die Haelfte der Gueltigkeitsdauer verstrichen ist (bei 10 Jahren also nach 5 Jahren). Trag dir dieses Datum bereits bei der Installation als Aufgabe ein - eine abgelaufene Issuing-CA macht schlagartig alle ausgestellten Zertifikate ungueltig, unabhaengig von deren eigener Restlaufzeit.

# Auf der Issuing-CA: Erneuerungsantrag erzeugen (mit neuem Schluesselpaar)
certreq -renewcert -kmpc "Microsoft Software Key Storage Provider" C:\transfer\subca_renew.req

Monitoring und Betrieb

Ein paar KQL-Abfragen (falls du Certificate-Services-Events per Sentinel/Log Analytics sammelst) helfen, Auffaelligkeiten frueh zu erkennen:

// Fehlgeschlagene Zertifikatsanforderungen der letzten 24h
Event
| where Source == "Microsoft-Windows-CertificationAuthority"
| where EventID == 22 // Anforderung fehlgeschlagen
| where TimeGenerated > ago(24h)
| project TimeGenerated, Computer, RenderedDescription

// Ausgestellte Zertifikate mit ungewoehnlich langer Gueltigkeit (moeglicher Vorlagenmissbrauch)
CertificateServicesLog_CL
| where ValidityDays_d > 730
| project TimeGenerated, RequesterName_s, TemplateName_s, ValidityDays_d

Ergaenzend lohnt sich ein monatlicher Lauf von PSPKIAudit oder Certipy (Linux-Tool, per LDAP gegen die CA), um Fehlkonfigurationen wie ESC1-ESC8 aufzudecken - gerade weil Zertifikatsvorlagen sich im Alltag schleichend veraendern (neue Admin-Kollegin klickt “Vollzugriff” statt “Registrieren”, und keiner merkt es).

Haeufige Fallstricke in der Praxis

• Root-CA-VM verloren gegangen: Wenn die Offline-Root nur als VM ohne Backup existiert und der Hypervisor-Host ausfaellt, ist die gesamte PKI-Kette futsch. Backup der Root-CA (VM-Snapshot + separates Backup des Private-Key-Exports) ist Pflicht, genauso wie ein Recovery-Runbook.
• Zu kurze CRL-Gueltigkeit bei der Root: Wenn du vergisst, die Root regelmaessig hochzufahren und die CRL zu erneuern, faellt irgendwann die komplette Kette aus. 6-12 Monate CRL-Gueltigkeit bei der Root ist ueblich, mit Erinnerung im Kalender.
• Vorlagenberechtigungen zu grosszuegig: “Domaenen-Benutzer” oder “Jeder” auf einer Vorlage mit Client-Auth-EKU und frei waehlbarem Subject ist der oben beschriebene ESC1-Klassiker.
• CDP/AIA nur intern erreichbar: Fuehrt zu Fehlern bei VPN-losen Homeoffice-Clients oder Partnerzugriffen, die die Sperrliste nicht laden koennen.
• Kein Key-Archival fuer Verschluesselungszertifikate: Wenn ein Mitarbeiter sein S/MIME-Verschluesselungszertifikat verliert (z. B. Profil kaputt) und kein Key-Recovery-Agent eingerichtet ist, sind alle damit verschluesselten E-Mails/Dateien unwiederbringlich weg.
• CA auf einem DC installiert: Siehe Warnung oben - vermischt Tier-0-Risiken maximal ungluecklich.

Weiterlernen

• PKI design considerations using Active Directory Certificate Services (Microsoft Learn)
• Configure the CDP and AIA Extensions (Microsoft Learn)
• Prepare the CAPolicy.inf File (Microsoft Learn)
• certutil Referenz (Microsoft Learn)
• ADCS Auto Enrollment konfigurieren (Boddenberg.de)
• Certified Pre-Owned: Abusing Active Directory Certificate Services (SpecterOps)

Verwandte Themen: Active Directory Grundlagen, AD Security Hardening und Tier-Modell, Gruppenrichtlinien (GPO) Grundlagen, SSL/TLS-Zertifikate verstehen, 802.1X Netzwerkzugangskontrolle, IT-Security-Grundlagen im KMU