ADCS-Migration Schritt für Schritt – inkl. CA-Backup und Wiederherstellung

Kurzfassung vorab

Eine ADCS-Migration ist kein Klick-Marathon, sondern eine Backup-Übung mit angeschlossenem Serverwechsel. Der sichere Standardweg im Mittelstand ist die Side-by-Side-Migration: neuer Host, Übernahme von CA-Datenbank und privatem Schlüssel, Parallelbetrieb mit Rückfalloption. Inplace-Upgrades sind verlockend schnell, aber rollbackfeindlich – und das Backup, das du nie getestet hast, ist im Ernstfall kein Backup. Wer eine Sache mitnimmt: Der private Schlüssel ist das einzige unersetzliche Teil. Geht er verloren, baust du die PKI neu auf.

Abb. 1: Die drei Migrationswege im Vergleich – Aufwand, Risiko und Eignung. Side-by-Side ist der Default für die meisten Projekte.

1. Drei Wege zur neuen CA – und warum nur einer der Default ist

Bevor du auch nur ein Backup ziehst, musst du wissen, welche Migrationsstrategie du fährst. Es gibt drei, und sie unterscheiden sich nicht in der PowerShell, sondern im Risiko. Die schlechte Nachricht zuerst: Der schnellste Weg ist auch der gefährlichste.

Inplace-Upgrade heißt: Du hebst das Betriebssystem des CA-Servers an (etwa 2016 auf 2022), die CA bleibt auf derselben Maschine. Das geht technisch, ist aber ein Drahtseilakt ohne Netz – läuft das Upgrade schief, hast du keinen sauberen Rückweg außer einem Restore. In gewachsenen Umgebungen mit Altlasten ist das ein Vabanquespiel.

Side-by-Side-Migration baut eine neue Maschine auf, installiert die ADCS-Rolle frisch und spielt das Backup der alten CA dort ein. Der Clou: Die alte CA läuft die ganze Zeit weiter. Geht etwas schief, ziehst du einfach den Stecker am Neuen und keiner merkt etwas. Das ist der Weg, den ich in praktisch jedem Mittelstandsprojekt gehe.

Komplette Neu-PKI baut eine frische Hierarchie parallel auf und rollt schrittweise um. Maximaler Aufwand, maximale Sauberkeit – sinnvoll genau dann, wenn die Altumgebung historisch verkorkst oder kompromittiert ist und du dem alten Trust schlicht nicht mehr traust.

2. Was du sichern musst – und was die meisten vergessen

Eine ADCS-CA besteht aus vier Bausteinen, die zusammengehören. Das Backup ist nur dann ein Backup, wenn alle vier dabei sind. Der Klassiker im Consulting-Alltag: jemand sichert brav die CA-Datenbank, aber nicht den privaten Schlüssel – und steht beim Restore vor einer hübschen, aber wertlosen Datensammlung.

Abb. 2: Die vier Bausteine eines vollständigen CA-Backups. Datenbank und privater Schlüssel sind zwingend, Registry und Konfiguration sparen beim Restore Stunden.

Die vier Bausteine im Klartext:

3. Side-by-Side Schritt für Schritt

Der konkrete Ablauf einer Side-by-Side-Migration. Die alte CA bleibt bis zum verifizierten Cut-over unangetastet – das ist die ganze Idee hinter dem Verfahren.

Abb. 3: Der Migrationsablauf als Sequenz. Erst wenn das Test-Enrollment gegen die neue CA sauber läuft, stoppt die alte die Ausstellung.

4. Die typischen Stolperfallen

Migrationen scheitern selten an der CA-Datenbank. Sie scheitern an den Dingen drumherum – Pfaden, Namen, Schlüsseln. Hier die Verdächtigen, die im Consulting-Alltag immer wieder auftauchen.

5. Cut-over und das Abschalten der Alt-CA

Der häufigste Fehler kommt nach der Migration: Die alte CA wird zu früh entsorgt. Sie hat aber noch einen Job – ihre CRL hält alle von ihr ausgestellten Zertifikate validierbar. Schaltest du sie ab, brechen schlagartig die Revocation-Checks weg.

Abb. 4: Die Overlap-Zone ist Absicht. Die Alt-CA bleibt als CRL-Lieferant online, bis ihre letzten Zertifikate abgelaufen sind.

Praxis-Beispiel

Ausgangslage: Die Trendforge Digital GmbH (Tech-Scaleup, rund 400 Mitarbeiter, cloud-affin) betreibt eine zweistufige PKI mit einer Issuing CA auf Windows Server 2016. Das OS läuft aus dem Support, die CA soll auf Server 2025 umziehen – ohne dass die rund 1.800 ausgestellten Geräte- und Nutzerzertifikate Schaden nehmen.

Maßnahme: Wir entscheiden uns für Side-by-Side. Backup der Alt-CA mit Backup-CARoleService inklusive privatem Schlüssel, neue VM mit identischem CA-Namen, Restore eingespielt. CDP/AIA bleiben auf einem DFS-Pfad, der unabhängig vom Hostnamen erreichbar ist – also kein URL-Umzug nötig. Test-Enrollment gegen einen Pilot-Client, dann Cut-over.

Ergebnis: Der Cut-over selbst dauerte unter einer Stunde, kein Anwender bemerkte etwas. Die Alt-CA blieb als CRL-Lieferant zwölf Monate online, bis das letzte 1-Jahres-Zertifikat ausgelaufen war, und ging dann sauber vom Netz. Kein einziges verwaistes Zertifikat, keine Validierungsfehler.

Verwandte Themen

Häufige Fragen (FAQ)

Wie sichere ich eine ADCS-CA vollständig?

Ein vollständiges Backup umfasst vier Teile: CA-Datenbank, privaten Schlüssel, CertSvc-Registry und die Konfigurationsdateien. Mit Backup-CARoleService und einem Passwort für den privaten Schlüssel bekommst du Datenbank und Schlüssel in einem Rutsch. Die Registry exportierst du separat. Wichtig: Teste den Restore einmal in einer Testumgebung, sonst ist es kein Backup, sondern eine Hoffnung.

Was ist der Unterschied zwischen Inplace und Side-by-Side?

Inplace hebt das Betriebssystem auf derselben Maschine an, die CA bleibt am Platz – schnell, aber ohne sauberen Rückweg. Side-by-Side baut eine neue Maschine auf und spielt das Backup dort ein, während die alte CA weiterläuft. Side-by-Side ist der sichere Standardweg, weil du jederzeit zurück kannst.

Warum muss der CA-Name bei der Migration gleich bleiben?

Der Common Name der CA steckt als Aussteller-Referenz in jedem ausgestellten Zertifikat. Änderst du ihn, verlieren alle Bestandszertifikate ihren Bezug zur CA und validieren nicht mehr. Wer einen neuen Namen will, braucht eine komplette Neu-PKI, keine Migration.

Wann darf ich die alte CA abschalten?

Erst wenn das letzte von ihr ausgestellte Zertifikat abgelaufen oder umgezogen ist. Bis dahin muss die alte CA ihre CRL weiter veröffentlichen, damit Revocation-Checks funktionieren. Bei 1-Jahres-Zertifikaten bedeutet das rund zwölf Monate Parallelbetrieb der CRL.

Was passiert mit dem privaten Schlüssel bei einer HSM-CA?

Bei einer HSM-CA liegt der private Schlüssel im HSM und wird nicht über Backup-CARoleService mitgesichert. Du musst den Schlüssel separat im HSM sichern oder den identischen HSM-Provider auf dem Zielsystem bereitstellen. Ohne passenden Provider lässt sich der Schlüssel auf der neuen Maschine nicht laden.

Wie teste ich, ob die Migration erfolgreich war?

Prüfe nach dem Restore den CA-Namen mit certutil -getreg CA\CommonName und kontrolliere die übernommenen Zertifikate. Danach machst du ein Test-Enrollment mit einem Pilot-Client gegen die neue CA. Läuft das sauber und sind CDP/AIA erreichbar, ist die Migration verifiziert – erst dann stoppst du die Ausstellung auf der alten CA.

Nächste Schritte mit boddenberg.de

Eine Migration ist der Moment, in dem sich zeigt, ob die PKI sauber dokumentiert war. Wenn du nicht allein durch den Cut-over willst:

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund