ADCS Offline Root CA aufsetzen
Die Vertrauensanker einer PKI – isoliert, selten gestartet, immer kritischOffline Root CA korrekt aufsetzen – Schritt für Schritt
Die Offline Root ist die oberste Vertrauensinstanz deiner PKI – und genau deshalb gehört sie nicht ins Netz. „Offline“ heißt wörtlich: nicht in der Domäne, nicht am Netzwerk, normalerweise heruntergefahren, idealerweise eine verschlüsselte VM auf einem isolierten Host, die nur für Signaturen kurz läuft. Sie signiert ausschließlich die Issuing CAs – sonst nichts. Wer die Root übernimmt, übernimmt die komplette PKI. Diese Anleitung zeigt, wie du sie sauber aufsetzt, ohne dir die typischen Air-Gap-Fallen einzufangen.
Abb. 1: Die Offline Root im Air-Gap. Anfrage raus, signiertes Zertifikat und CRL rein – ausschließlich per Datenträger.
1. Was „offline“ wirklich bedeutet
Offline ist kein Adjektiv, sondern ein Betriebskonzept. Eine Root, die „eigentlich offline“ ist, aber in der Domäne hängt und durchläuft, ist nicht offline – sie ist nur unbenutzt online. Der Sicherheitsgewinn entsteht durch drei Eigenschaften:
In der Praxis ist die Root meist eine verschlüsselte VM, die auf einem isolierten Host liegt und nur für die wenigen Anlässe hochgefahren wird. Der Datenaustausch läuft über einen Datenträger – ein bewusster Medienbruch, kein Kabel.
|
Info · Offline Root und Architektur Die Offline Root ist das definierende Element der zweistufigen Architektur. Wie sich zwei- gegen ein- und dreistufige Hierarchien schlagen, zeigt Spoke 1.4. Wer noch grundsätzlich plant, findet im Aufbau-Spoke den Gesamtablauf, in den dieser Schritt eingebettet ist. |
|---|
2. Vorbereitung: die VM und die CAPolicy.inf
Bevor die Rolle installiert wird, steht die Vorbereitung. Die VM bekommt keine Netzwerkkarte (oder eine deaktivierte), wird verschlüsselt und ist kein Domänenmitglied. Datum und Zeitzone setzt du sauber, denn die Root signiert langlebige Zertifikate – ein falsches Datum vererbt sich über Jahre.
Der wichtigste Vorbereitungsschritt ist die CAPolicy.inf. Sie muss vor der Konfiguration der Rolle nach C:\Windows liegen, weil ADCS sie genau einmal beim Setup ausliest:
|
CAPolicy.inf für die Offline Root |
|---|
|
[Version] Signature="$Windows NT$"
[Certsrv_Server] ; 20 Jahre Gueltigkeit, RSA 4096 beim Renewal RenewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=20 ; Lange CRL-Gueltigkeit, da die Root selten laeuft CRLPeriod=Years CRLPeriodUnits=1 ; Keine Delta-CRL auf der Root CRLDeltaPeriod=Days CRLDeltaPeriodUnits=0 ; Leere Policy-Statement-Sektion = keine vererbten Constraints [PolicyStatementExtension] Policies= |
|
Warnung · Die CRL-Gültigkeit ist eine Falle Die Root-CRL muss lange genug gültig sein, um zwischen den seltenen Hochfahr-Terminen nicht abzulaufen. Setzt du sie auf eine Woche, läuft sie zwischen zwei Wartungen ab – und dann ist die gesamte Vertrauenskette ungültig, weil Clients die Root-CRL nicht mehr prüfen können. Ein Jahr ist ein vernünftiger Startwert. Trage dir den Erneuerungstermin in den Kalender, nicht ins Gedächtnis. |
|---|
3. Installation und Konfiguration der Root
Jetzt wird die Rolle installiert – als Standalone Root, ohne Web-Enrollment (das hat auf einer Offline-Maschine nichts verloren):
|
Offline Root installieren und konfigurieren |
|---|
|
# Rolle hinzufuegen (NUR die CA-Rolle, kein Web-Enrollment) Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
# Standalone Root: 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 auf eine HTTP-URL legen, die spaeter ONLINE erreichbar ist $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
# CRL-Gueltigkeit setzen und erste CRL erzeugen certutil -setreg CA\CRLPeriodUnits 1 certutil -setreg CA\CRLPeriod "Years" Restart-Service certsvc certutil -CRL |
|
Praxis-Tipp · HSM lohnt sich genau hier Wenn du irgendwo in der PKI ein HSM einsetzt, dann an der Root. Ihr privater Schlüssel ist das wertvollste Geheimnis der gesamten Infrastruktur – wird er kopiert, ist die PKI verloren. Ein HSM verhindert, dass der Schlüssel die Hardware je verlässt. Ein YubiHSM 2 reicht für viele Mittelstandsszenarien. Welche HSM-Klasse zu welchem Schutzbedarf passt, zeigt Spoke „HSM-Auswahl für ADCS“. |
|---|
4. Die Issuing CA signieren – der Medienbruch in der Praxis
Die eigentliche Aufgabe der Root: die Issuing CA signieren. Der Ablauf ist bewusst umständlich, weil der Medienbruch der Sicherheitsgewinn ist.
|
Auf der Root: Anfrage einreichen und ausstellen |
|---|
|
# Anfrage einreichen (gibt eine RequestId zurueck) certreq -submit "D:\IssuingCA.req"
# Anfrage genehmigen und ausstellen certutil -resubmit <RequestId>
# Ausgestelltes Zertifikat exportieren certreq -retrieve <RequestId> "D:\IssuingCA.crt"
# Root-Zertifikat und aktuelle CRL fuer die Veroeffentlichung mitnehmen certutil -ca.cert "D:\RootCA.crt" certutil -CRL # erzeugte .crl liegt unter C:\Windows\System32\CertSrv\CertEnroll\ |
5. Die Root-CRL ohne Netz veröffentlichen
Hier liegt die Tücke: Die Root läuft offline, aber ihre CRL muss online erreichbar sein, sonst können Clients die Vertrauenskette nicht prüfen. Der Weg führt über denselben Medienbruch.
Abb. 2: Die Root-CRL wandert per Datenträger in das HTTP-CDP-Verzeichnis. Läuft sie ab, ist die ganze Kette ungültig.
Praktisch: Du exportierst die CRL auf der Root, trägst sie per Datenträger zum HTTP-Webserver (IIS reicht) und legst sie in das CDP-Verzeichnis. Diesen eleganten Weg ohne dauerhafte Netzwerkanbindung der Root vertieft der Spoke
„CRL-Veröffentlichung der Offline Root“. Der entscheidende Punkt bleibt: Die CRL-Gültigkeit der Root muss lang genug sein, damit sie zwischen den Wartungsterminen nicht abläuft.
Abb. 3: Die wenigen Anlässe, zu denen die Root überhaupt läuft. Dazwischen bleibt sie heruntergefahren.
Praxis-Beispiel: Trendforge Digital GmbH
Die Trendforge Digital GmbH, ein cloud-affines Scaleup, hatte beim ersten Aufbau einen klassischen Fehler gemacht: Die „Offline“ Root lief als ganz normale VM mit Netzwerkanbindung durch, weil das „praktischer“ war. Beim Security-Review war das der erste Befund.
Der Umbau war überschaubar: Die Root wurde auf einen isolierten Host migriert, die Netzwerkkarte entfernt, die VM verschlüsselt und ein fester Wartungsrhythmus für die CRL-Erneuerung etabliert – ein Kalendereintrag mit Vorlauf, damit die Jahres-CRL nie abläuft. Der Datenaustausch läuft seither ausschließlich über einen dedizierten Datenträger. Aufwand: ein guter halber Tag. Sicherheitsgewinn: die Root ist remote schlicht nicht mehr erreichbar.
Verwandte Themen
Häufige Fragen (FAQ)
Muss die Offline Root eine physische Maschine sein?
Nein, eine verschlüsselte VM auf einem isolierten Host ist üblich und völlig ausreichend. Entscheidend ist nicht physisch oder virtuell, sondern dass sie kein Netzwerk hat, kein Domänenmitglied ist und normalerweise heruntergefahren bleibt. Die Verschlüsselung schützt den Schlüssel, falls die VM-Datei abhandenkommt.
Warum darf die Root nicht in der Domäne sein?
Damit eine kompromittierte Domäne die Root nicht mitreißt. Eine Standalone-CA hat keine Abhängigkeit zum Active Directory und ist damit von Domänen-Angriffen entkoppelt. Genau diese Entkopplung ist der Sinn der zweistufigen Architektur.
Wie oft muss ich die Root überhaupt hochfahren?
Selten: beim einmaligen Setup, beim Signieren neuer Issuing CAs und beim Erneuern der Root-CRL, typischerweise einmal jährlich. Dazwischen bleibt sie heruntergefahren. Genau das macht sie sicher – eine Maschine, die nicht läuft, lässt sich schwer angreifen.
Was passiert, wenn die Root-CRL abläuft?
Dann können Clients die Gültigkeit der Vertrauenskette nicht mehr prüfen, und im Ergebnis wird die gesamte PKI als ungültig behandelt – mit Auswirkungen auf WLAN, VPN und Logon. Deshalb muss die CRL-Gültigkeit lang genug sein und der Erneuerungstermin fest eingeplant werden.
Brauche ich für die Root zwingend ein HSM?
Zwingend nur in regulierten Umgebungen (NIS2, BSI, eIDAS, KRITIS). Empfehlenswert ist es überall dort, wo der Schutz des Root-Schlüssels kritisch ist – also faktisch fast immer. Der Root-Schlüssel ist das wertvollste Geheimnis der PKI; ein HSM verhindert, dass er die Hardware verlässt.
Wie tausche ich Daten mit einer Maschine ohne Netzwerk aus?
Über einen dedizierten Datenträger, klassisch einen USB-Stick. Die Anfrage der Issuing CA geht so zur Root, das signierte Zertifikat und die CRL gehen so zurück. Dieser bewusste Medienbruch ist kein Umstand, sondern der eigentliche Sicherheitsmechanismus.
Nächste Schritte mit boddenberg.de
Die Offline Root ist das Fundament, auf dem alles andere steht. Wenn du unsicher bist, ob deine Root wirklich sauber isoliert ist – oder ob sie nur „eigentlich offline“ läuft – lohnt sich ein gezielter Blick.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund