ADCS Aufbau von Grund auf
Zweistufige PKI in der richtigen Reihenfolge – damit du nicht zweimal baustAufbau einer ADCS-Umgebung von Grund auf
Eine ADCS-Umgebung baust du nicht „mit dem Wizard durchklicken“ – jedenfalls nicht, wenn sie einen Audit überstehen soll. Die Reihenfolge ist entscheidend: erst planen und Namen festlegen, dann die Offline Root, dann die Issuing CA, dann CDP/AIA, dann Templates und Auto-Enrollment, zum Schluss Härtung und Doku. Wer die CAPolicy.inf vergisst oder die Veröffentlichungspfade erst nachträglich setzt, baut zuverlässig zweimal. Diese Anleitung zeigt die Zielarchitektur und die sechs Schritte dahin – inklusive der PowerShell-Befehle, die du wirklich brauchst.
Abb. 1: Die Zielarchitektur – zweistufig mit getrennter Veröffentlichungsschicht. Genau hierhin arbeiten wir uns vor.
1. Bevor du irgendetwas installierst: das Namenskonzept
Der häufigste Fehler passiert vor der ersten Installation: Man legt los, ohne CA-Namen, Gültigkeiten und Veröffentlichungspfade festzulegen. Das rächt sich, weil der CA-Name und die CDP/AIA-URLs nach der Installation praktisch in Stein gemeißelt sind. Ein nachträglicher Wechsel bedeutet Neuaufbau.
Lege also vorab schriftlich fest:
|
Warnung · Der teuerste Tippfehler Der CA-Name landet im Subject jedes ausgestellten Zertifikats und in jeder CRL. Wer nach drei Monaten merkt, dass „SRV2019CA“ eine blöde Idee war, kann ihn nicht umbenennen – die komplette Vertrauenskette hängt daran. Plane den Namen so, als müsstest du ihn noch 2040 erklären. Denn das musst du wahrscheinlich. |
|---|
2. Die Offline Root CA installieren
Die Root CA wird als Standalone CA installiert – nicht in der Domäne, nicht im Netz. Sie hat genau eine Aufgabe: die Issuing CA zu signieren. Danach wird sie heruntergefahren und nur noch für CRL-Erneuerung und neue Sub-CAs kurz hochgefahren. Warum offline, erklärt der Spoke
„Offline Root CA korrekt aufsetzen“ im Detail. Hier die Kurzfassung der Installation.
Vor der Rolleninstallation kommt die CAPolicy.inf nach C:\Windows. Sie steuert Schlüssellänge, Gültigkeit und CRL-Verhalten der Root:
|
CAPolicy.inf für die Offline Root (nach C:\Windows kopieren) |
|---|
|
[Version] Signature="$Windows NT$"
[Certsrv_Server] ; Root-Gueltigkeit 20 Jahre, kein automatisches Renewal der Endzertifikate RenewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=20 ; CRL der Root lange gueltig, da selten erneuert CRLPeriod=Years CRLPeriodUnits=1 CRLDeltaPeriod=Days CRLDeltaPeriodUnits=0 AlternateSignatureAlgorithm=0 |
Erst danach die Rolle installieren und konfigurieren:
|
Root CA installieren (Standalone, Offline) |
|---|
|
# Rolle hinzufuegen (ohne Web-Enrollment auf der Root!) Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
# Standalone Root konfigurieren, RSA 4096, SHA-256, 20 Jahre Install-AdcsCertificationAuthority ` -CAType StandaloneRootCA ` -CACommonName "Musterwerk Root CA" ` -KeyLength 4096 ` -HashAlgorithmName SHA256 ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -ValidityPeriod Years -ValidityPeriodUnits 20 ` -Force
# CDP/AIA-Pfade fuer die spaetere HTTP-Veroeffentlichung setzen $http = "http://pki.musterwerk.de" Add-CACRLDistributionPoint -Uri "$http/cdp/%3%8%9.crl" ` -AddToCertificateCdp -Force Add-CAAuthorityInformationAccess -Uri "$http/cdp/%3%4.crt" ` -AddToCertificateAia -Force Restart-Service certsvc |
3. Die Issuing CA installieren und von der Root signieren lassen
Die Issuing CA ist eine Enterprise Subordinate CA – sie ist in der Domäne, kennt Active Directory und macht die eigentliche Arbeit im Tagesbetrieb. Der Ablauf: Rolle installieren, Zertifikatsanfrage erzeugen, diese Anfrage auf die Offline Root tragen, dort signieren, das ausgestellte CA-Zertifikat zurück auf die Issuing CA installieren.
|
Issuing CA installieren (Enterprise Sub-CA) |
|---|
|
Install-WindowsFeature ADCS-Cert-Authority, ADCS-Web-Enrollment ` -IncludeManagementTools
# Enterprise Sub-CA: erzeugt eine Anfrage-Datei (.req), KEIN fertiges Zert Install-AdcsCertificationAuthority ` -CAType EnterpriseSubordinateCA ` -CACommonName "Musterwerk Issuing CA" ` -KeyLength 4096 -HashAlgorithmName SHA256 ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -OutputCertRequestFile "C:\IssuingCA.req" ` -Force
# — Die .req-Datei jetzt per USB auf die Offline Root tragen — # Auf der ROOT: Anfrage einreichen und ausstellen # certreq -submit C:\IssuingCA.req # certutil -resubmit <RequestId> # Ausgestelltes .crt zurueck auf die Issuing CA tragen und installieren: certutil -installCert "C:\IssuingCA.crt" Start-Service certsvc |
|
Info · Warum erst Anfrage, dann Signatur Eine Sub-CA stellt sich ihr eigenes Zertifikat nicht selbst aus – sonst wäre die Hierarchie wertlos. Die Issuing CA erzeugt nur einen Antrag, die Offline Root entscheidet, ob sie ihn signiert. Genau dieser Medienbruch (USB-Stick statt Netzwerk) ist der Sicherheitsgewinn der zweistufigen Architektur. Wie eine zweistufige Hierarchie gegenüber ein- und dreistufig abschneidet, zeigt Spoke 1.4. |
|---|
4. CDP und AIA veröffentlichen – der Schritt, den alle vergessen
Ein Zertifikat ist nur so vertrauenswürdig wie die Möglichkeit, seine Gültigkeit zu prüfen. Dafür braucht der Client zwei Dinge: die Vertrauenskette (über die AIA-URL) und die Information, ob das Zertifikat widerrufen wurde (über die CDP-URL, also die CRL). Bei einer Offline Root ist das besonders heikel, weil ihre CRL ja nicht automatisch ins Netz kommt.
Abb. 2: Gültigkeitsprüfung über AIA, CDP und optional OCSP. Ohne erreichbare HTTP-Pfade scheitert jede domänenfremde Prüfung.
Praktisch heißt das: Du richtest einen schlichten HTTP-Webserver ein (IIS reicht), unter dem CRL und CA-Zertifikate liegen. Die Root-CRL kopierst du nach jeder Erneuerung manuell dorthin. Den eleganten Weg ohne Netzwerkanbindung der Root beschreibt der Spoke
„CRL-Veröffentlichung der Offline Root“.
|
Praxis-Tipp · HTTP schlägt LDAP Standardmäßig veröffentlicht ADCS CDP/AIA auch über LDAP. Das funktioniert prima für Domänenmitglieder – und gar nicht für alles andere: Smartphones, Linux-Server, Partner-Geräte. Setze immer eine HTTP-URL an erste Stelle. Wer nur LDAP nutzt, wundert sich später, warum das iPhone das WLAN-Zertifikat nicht prüfen kann. |
|---|
5. Templates und Auto-Enrollment
Jetzt erst wird die CA nützlich. Über Zertifikatsvorlagen (Templates) legst du fest, wer welche Zertifikate für welchen Zweck bekommt. Eine frische Vorlage dupliziert man immer von einer bestehenden – niemals die Originale anfassen.
|
Template-Status und Auto-Enrollment prüfen |
|---|
|
# Welche Templates sind auf der Issuing CA veroeffentlicht? certutil -CATemplates | Format-List
# Auf den Clients das Enrollment anstossen (statt aufs GPO-Intervall warten) gpupdate /force certutil -pulse
# Pruefen, welche Maschinenzertifikate angekommen sind Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, @{N="Template";E={ ($_.Extensions | Where-Object { $_.Oid.FriendlyName -match "Template" }).Format(0) }} | Format-Table -AutoSize |
Die Steuerung läuft über zwei GPO-Einstellungen (Computer- und User-Konfiguration) plus das „Autoenroll“-Recht auf der jeweiligen Vorlage. Die typischen Stolperfallen – falsche Berechtigungen, vergessene Veröffentlichung, Cache-Probleme – behandelt der Spoke
„Auto-Enrollment konfigurieren“ ausführlich. Welche Template-Version wann passt, klärt
„Zertifikatsvorlagen v2 vs. v3 vs. v4“.
6. Härten, dokumentieren, übergeben
Eine frisch installierte ADCS-Umgebung ist noch keine sichere. Vor dem Produktivgang gehören drei Dinge erledigt: der ESC-Check, die Grundhärtung und die Notfalldokumentation.
Die Härtung nach Standard beschreibt Spoke „ADCS-Härtung nach BSI IT-Grundschutz“. Die Aufbaureihenfolge im Überblick:
Abb. 3: Die sechs Schritte von der leeren Maschine bis zur produktiven, gehärteten PKI.
Praxis-Beispiel: Musterwerk GmbH
Die Musterwerk GmbH, ein Industrie-Mittelständler mit rund 1.200 Mitarbeitern, hatte eine „historisch gewachsene“ einstufige CA, die irgendwann mal jemand mit dem Wizard hingeklickt hatte – ohne CAPolicy.inf, mit LDAP-only-CDP und einem CA-Namen, der den alten Serverhostnamen enthielt.
Der Neuaufbau lief exakt nach der Reihenfolge oben: erst ein sauberes Namenskonzept, dann eine Offline Root als verschlüsselte, normalerweise heruntergefahrene VM, dann die Enterprise Issuing CA mit HTTP-CDP/AIA. Das Ergebnis: keine LDAP-Abhängigkeit mehr, prüfbare Zertifikate auch auf den Maschinensteuerungen und Tablets in der Fertigung, und ein CA-Name, der die nächste Server-Generation überlebt. Aufwand: zwölf Personentage inklusive Migration der bestehenden Vorlagen.
Verwandte Themen
Häufige Fragen (FAQ)
Muss die Root CA wirklich offline sein?
Für jede Umgebung mit Anspruch an Sicherheit oder Audit-Tauglichkeit: ja. Wer die Root übernimmt, übernimmt die komplette PKI. Eine offline gehaltene, normalerweise heruntergefahrene Root reduziert die Angriffsfläche auf die wenigen Momente, in denen sie für Signaturen läuft. Einstufig ohne Offline Root geht technisch, ist aber kaum zu retten, wenn etwas schiefgeht.
Was ist die CAPolicy.inf und warum muss sie zuerst da sein?
Die CAPolicy.inf steuert grundlegende Parameter wie Schlüssellänge, Gültigkeit und CRL-Verhalten der CA. Sie muss vor der Konfiguration der Rolle nach C:\Windows liegen, weil ADCS sie genau einmal beim Setup ausliest. Vergisst du sie, installiert ADCS mit Defaults, die du hinterher kaum noch sauber änderst.
Warum erzeugt die Issuing CA erst eine Anfrage statt eines fertigen Zertifikats?
Weil eine untergeordnete CA ihr eigenes Zertifikat nicht selbst ausstellen darf – sonst wäre die Hierarchie sinnlos. Sie erzeugt einen Antrag, den die Offline Root signiert. Dieser bewusste Medienbruch per USB-Stick ist der eigentliche Sicherheitsgewinn der zweistufigen Architektur.
Brauche ich für den Aufbau zwingend ein HSM?
Für die meisten Mittelstandsszenarien nicht zwingend, aber für die Root empfehlenswert, sobald Compliance-Anforderungen (NIS2, BSI, eIDAS) im Spiel sind. Ein YubiHSM 2 reicht oft. Software-Schlüssel gehen technisch, sind aber bei Audits schwerer zu verteidigen.
Wie lange dauert ein sauberer Aufbau realistisch?
Ein zweistufiges Standardszenario im Mittelstand liegt erfahrungsgemäß bei 10 bis 15 Personentagen – inklusive Namenskonzept, Härtung, Templates, Auto-Enrollment und Dokumentation. Das reine Durchklicken ist in einem Nachmittag erledigt, aber genau das ist nicht das Ziel.
Kann ich CDP/AIA nachträglich ändern?
Eingeschränkt. Neue URLs gelten nur für künftig ausgestellte Zertifikate; bereits ausgestellte tragen die alten Pfade fest im Zertifikat. Deshalb müssen die Veröffentlichungspfade stehen, bevor die ersten produktiven Zertifikate rausgehen.
Nächste Schritte mit boddenberg.de
Ein Neuaufbau ist der Moment, an dem sich entscheidet, ob die PKI die nächsten zehn Jahre trägt oder zum Dauerproblem wird. Hier lohnt sich eine saubere Planung von Anfang an.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund