Side-by-Side-Migration im Detail – die unterschätzten Stolperfallen

Kurzfassung vorab

Eine Side-by-Side-Migration ist der sichere Weg zur neuen CA – aber sie scheitert selten am Verfahren, sondern an fünf Details. Vier davon scheitern still: Die Migration wirkt erfolgreich, und erst Wochen später brechen Validierungen weg. CA-Name, CDP/AIA-Pfade, exportierbarer Schlüssel, Template-Veröffentlichung und der Zeitpunkt des Abschaltens – wer diese fünf Punkte sauber abhakt, hat eine langweilige Migration. Und langweilig ist bei PKI das höchste Lob.

Abb. 1: Die fünf neuralgischen Punkte einer Side-by-Side-Migration. Der Grundablauf steht in Spoke 4.1 – hier geht es um die Details.

1. Falle CA-Name: ein Zeichen zu viel und alles ist hin

Der Common Name der CA ist in jedem ausgestellten Zertifikat als Aussteller-Referenz verankert. Bei der Side-by-Side-Migration muss die neue CA exakt denselben Namen tragen wie die alte – Zeichen für Zeichen, inklusive Leerzeichen und Sonderzeichen. Schon eine Abweichung sorgt dafür, dass die Bestandszertifikate ihren Bezug zur CA verlieren.

Die Tücke: Beim Restore auf eine frisch installierte Rolle fragt der Assistent nach dem CA-Namen. Wer hier aus dem Gedächtnis tippt oder die Gelegenheit für einen „schöneren“ Namen nutzt, hat die Migration schon verloren. Den Namen vorher per certutil auslesen und kopieren, nicht abtippen.

2. Falle CDP/AIA: wenn der Hostname zur Zeitbombe wird

Das ist die heimtückischste Falle, weil sie verzögert zuschlägt. Jedes ausgestellte Zertifikat trägt feste URLs für die CRL (CDP) und das CA-Zertifikat (AIA). Diese Pfade sind eingebrannt und unveränderbar. Wenn die neue CA einen anderen Hostnamen hat und die Pfade auf den alten Host zeigen, funktioniert zunächst alles – solange die Alt-CA noch läuft.

Abb. 2: Zeigen die CDP/AIA-Pfade auf den alten Host, brechen die Revocation-Checks, sobald die Alt-CA aus ist. Host-unabhängige Pfade lösen das.

Schaltest du die Alt-CA Wochen später ab, zeigen die alten Zertifikate plötzlich auf eine tote URL. Der CRL-Abruf läuft ins Leere, der Revocation-Check schlägt fehl, und die Zertifikate gelten als ungültig. Der Fehler tritt mit Verzögerung auf – genau dann, wenn niemand mehr an die Migration denkt.

3. Falle Schlüssel: nicht exportierbar ist nicht migrierbar

Der private CA-Schlüssel ist das einzige unersetzliche Teil. Wurde er bei der ursprünglichen CA-Installation als „nicht exportierbar“ markiert, lässt er sich nicht über das Standard-Backup mitnehmen – und das merkst du erst, wenn der Restore abbricht. Bei HSM-CAs liegt der Schlüssel im HSM und braucht denselben Provider auf dem Ziel.

4. Falle Templates: die CA läuft, stellt aber nichts aus

Diese Falle führt regelmäßig zu stundenlanger Fehlersuche an der falschen Stelle. Nach dem Restore läuft die CA, der Dienst ist grün, alles sieht gut aus – nur stellt sie keine Zertifikate aus. Der Grund: Die Zertifikatsvorlagen liegen zwar im AD und sind damit migriert, aber ihre Veröffentlichung auf der konkreten CA ist eine separate Zuweisung, die der Restore nicht mitbringt.

Abb. 3: Die Templates bleiben im AD, aber ihre Veröffentlichung auf der neuen CA ist ein eigener Schritt. Ohne ihn stellt die CA nichts aus.

Die Lösung ist simpel, wenn man die Ursache kennt: Die Templates müssen auf der neuen CA explizit veröffentlicht werden, per Konsole oder mit certutil -SetCATemplates. Erst dann nimmt die CA wieder Anträge an. Wer das nicht weiß, sucht den Fehler bei Auto-Enrollment, GPO oder Berechtigungen – überall, nur nicht an der richtigen Stelle.

5. Falle Abschalten: die Geduldsprobe nach dem Cut-over

Der Cut-over ist geschafft, die neue CA stellt aus, alle sind zufrieden – und genau hier passiert der letzte Fehler: Die Alt-CA wird abgeschaltet oder gar gelöscht. Aber sie hat noch einen Job. Ihre CRL hält alle von ihr ausgestellten Zertifikate validierbar. Schaltest du sie zu früh ab, brechen schlagartig die Revocation-Checks für alle Bestandszertifikate weg.

Die Alt-CA muss als CRL-Lieferant online bleiben, bis ihr letztes ausgestelltes Zertifikat abgelaufen oder erneuert ist. Bei 1-Jahres-Zertifikaten bedeutet das rund zwölf Monate Parallelbetrieb der CRL – auch wenn die CA längst keine neuen Zertifikate mehr ausstellt.

Abb. 4: Die Cut-over-Checkliste. Jeder Schritt hat eine Prüffrage – erst wenn alle grün sind, stoppt die Alt-CA die Ausstellung.

Praxis-Beispiel

Ausgangslage: Die Sparfuchs & Partner Steuerberatungs GmbH (kleiner Dienstleister, unter 100 Mitarbeiter, knappes Budget, hohe Compliance-Anforderungen) migriert ihre einzige Issuing CA auf neue Hardware. Der bisherige Dienstleister hatte die CDP/AIA-Pfade direkt auf den Servernamen gelegt.

Maßnahme: Bei der Bestandsaufnahme fällt die CDP/AIA-Falle sofort auf. Statt einfach umzuziehen, richten wir zuerst einen host-unabhängigen DNS-Namen (pki.sparfuchs.local) ein, ziehen die Veröffentlichung dorthin und renewen das CA-Zertifikat einmal, damit künftige Zertifikate den stabilen Pfad tragen. Erst dann läuft die eigentliche Side-by-Side-Migration. Nach dem Restore weisen wir die Templates explizit zu und prüfen mit pkiview.msc alle Pfade auf grün.

Ergebnis: Die Migration selbst war unspektakulär – genau das Ziel. Die alte CA blieb zwölf Monate als CRL-Lieferant online und ging dann sauber vom Netz. Künftige Migrationen sind dank des stabilen Pfades jetzt deutlich einfacher.

Verwandte Themen

Häufige Fragen (FAQ)

Warum stellt meine migrierte CA keine Zertifikate aus?

Höchstwahrscheinlich sind nach dem Restore keine Zertifikatsvorlagen auf der neuen CA veröffentlicht. Die Templates liegen zwar im AD, aber ihre Zuweisung zur konkreten CA bringt der Restore nicht mit. Weise die Vorlagen per Konsole oder mit certutil -SetCATemplates neu zu, dann nimmt die CA wieder Anträge an.

Was passiert, wenn sich der Hostname der CA ändert?

Wenn die CDP/AIA-Pfade auf den alten Hostnamen zeigen, brechen die Revocation-Checks, sobald die Alt-CA abgeschaltet wird. Die alten Zertifikate finden ihre CRL dann nicht mehr. Die saubere Lösung sind host-unabhängige Veröffentlichungspfade über DFS, Load Balancer oder einen dedizierten DNS-Namen.

Wie prüfe ich vor der Migration, ob der CA-Schlüssel exportierbar ist?

Mit certutil -store My siehst du das CA-Zertifikat und seine Schlüsseleigenschaften. Mache außerdem in einer Testumgebung ein Probe-Backup mit Backup-CARoleService. Bricht es ab, war der Schlüssel als nicht exportierbar markiert – das muss vor der echten Migration geklärt werden.

Wann darf ich die alte CA nach der Migration abschalten?

Erst wenn ihr letztes ausgestelltes Zertifikat abgelaufen oder erneuert ist. Bis dahin muss sie ihre CRL weiter veröffentlichen, damit die Bestandszertifikate validierbar bleiben. Bei 1-Jahres-Zertifikaten bedeutet das rund zwölf Monate Parallelbetrieb der CRL.

Wie stelle ich sicher, dass der CA-Name wirklich identisch ist?

Lies den Namen vor der Migration mit certutil -getreg CA\CommonName aus und kopiere den exakten String. Tippe ihn beim Restore nicht aus dem Gedächtnis ab. Schon eine kleine Abweichung sorgt dafür, dass die Bestandszertifikate ihren Bezug zur CA verlieren.

Wie verifiziere ich, dass die Migration wirklich erfolgreich war?

Arbeite eine Checkliste mit Prüffragen ab: CA-Name identisch, privater Schlüssel geladen, Templates veröffentlicht, CDP/AIA in pkiview.msc grün, Test-Enrollment mit einem Pilot-Client erfolgreich. Erst wenn alle Punkte grün sind, stoppst du die Ausstellung auf der alten CA.

Nächste Schritte mit boddenberg.de

Die meisten Migrationsfehler entstehen nicht bei der Ausführung, sondern bei der Planung. Eine Bestandsaufnahme vorab spart später die Fehlersuche:

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund