ADCS HSM-Migration
Private-Key-Migration von Software-CSP zu HSM-KSP – Vertrauenskette erhalten, Audit bestehenMigration einer Software-CA auf HSM-Betrieb
Irgendwann kommt bei fast jeder PKI der Moment, in dem das Audit, die NIS2-Einführung oder schlicht das gesunde Misstrauen fragt: Wo liegt eigentlich der private Schlüssel deiner CA? Wenn die Antwort „als Datei im Betriebssystem“ lautet, wird es Zeit für ein HSM. Meine klare Empfehlung: In rund 80 Prozent der Fälle migrierst du den bestehenden Schlüssel per Import ins HSM und behältst damit deine komplette Vertrauenskette – kein Neuausrollen von Stammzertifikaten, kein Bruch. Der gefährlichste Satz im ganzen Projekt ist trotzdem ein anderer: „Den alten Software-Schlüssel können wir doch schon mal löschen.“ Nein. Erst verifizieren, dann löschen – in genau dieser Reihenfolge.
Abb. 1: Die fünf Schritte der Migration – der alte Schlüssel fällt erst nach erfolgreicher Verifikation.
1. Zwei Wege: Schlüsselimport oder neue CA
Bevor du irgendetwas anfasst, fällst du eine grundsätzliche Entscheidung. Weg A: Du importierst den bestehenden privaten Schlüssel der CA ins HSM und stellst die CA so um, dass sie ihn künftig dort nutzt. Die CA bleibt dieselbe, alle ausgestellten Zertifikate bleiben gültig, die Vertrauenskette ist unberührt. Weg B: Du baust eine komplett neue CA mit einem frisch im HSM erzeugten Schlüssel auf und lässt die alte parallel auslaufen.
|
Kriterium |
Weg A: Schlüsselimport |
Weg B: Neue CA |
|---|---|---|
|
Vertrauenskette |
bleibt erhalten |
bricht / parallel |
|
Aufwand |
gering |
hoch |
|
Re-Enrollment nötig |
nein |
ja, alle Clients |
|
Schlüssel-Herkunft |
aus Software importiert |
im HSM erzeugt |
|
Empfohlen für |
80 % der Projekte |
CA-Wechsel ohnehin geplant |
Der Import erhält die Vertrauenskette und ist deshalb in den allermeisten Projekten der pragmatische Weg. Weg B lohnt sich nur, wenn ohnehin ein CA-Wechsel ansteht – etwa weil die alte CA einen zu kurzen Schlüssel oder einen veralteten Hash-Algorithmus nutzt und du diese Altlast gleich mit entsorgen willst. Reiner Purismus („ein im HSM erzeugter Schlüssel ist sauberer“) rechtfertigt den Re-Enrollment-Aufwand selten.
Abb. 2: Entscheidungsmatrix – Import erhält die Kette, Neu-CA erzwingt Re-Enrollment.
|
Info · Verweis Welches HSM überhaupt zu deinem Schutzbedarf und Budget passt – YubiHSM 2, Utimaco oder Thales Luna – klärt Spoke 3.3 „HSM-Auswahl für ADCS“. Die Auswahl ist die Voraussetzung, diese Migration der Umzug selbst. |
|---|
2. Vorbereitung: Backup ist nicht verhandelbar
Vor dem ersten echten Eingriff sicherst du die komplette CA – Datenbank, Konfiguration und den privaten Schlüssel. Das Schlüssel-Backup als passwortgeschützte PFX ist genau das, was du später ins HSM importierst. Ohne dieses Backup gibt es kein Zurück, falls beim Provider-Wechsel etwas schiefläuft.
|
PowerShell # Komplettes CA-Backup inklusive privatem Schluessel (PFX) # Das Passwort schuetzt den exportierten Schluessel – sicher verwahren! Backup-CARoleService -Path C:\\CA-Backup -Password (Read-Host -AsSecureString)
# Nur zur Kontrolle: aktuellen Provider der CA anzeigen certutil -getreg CA\\CSP\\Provider
# Registry-Sicherung der CA-Konfiguration reg export HKLM\\SYSTEM\\CurrentControlSet\\Services\\CertSvc\\Configuration C:\\CA-Backup\\ca-config.reg |
|---|
3. HSM und KSP installieren, Schlüssel importieren
Jetzt kommt das HSM ins Spiel. Du installierst den Treiber und den Key Storage Provider des Herstellers, schaltest die HSM-Partition frei und importierst den gesicherten privaten Schlüssel hinein. Ab diesem Moment existiert der Schlüssel an zwei Orten – noch in der Software und bereits im HSM. Das ist gewollt: Diese Überlappung ist dein Sicherheitsnetz.
|
PowerShell # Registrierte Provider pruefen – der HSM-KSP muss auftauchen certutil -csplist | Select-String "KSP"
# Privaten Schluessel aus der PFX in den HSM-KSP importieren # (Importmechanismus ist herstellerabhaengig – hier das ADCS-Prinzip) certutil -importpfx -csp "<HSM-KSP-Name>" C:\\CA-Backup\\ca-key.pfx
# Stoppt den CA-Dienst vor der Umstellung Stop-Service CertSvc |
|---|
4. CA auf den HSM-Provider umstellen
Nun teilst du der CA mit, dass sie ihren Schlüssel künftig nicht mehr aus dem Software-CSP, sondern aus dem HSM-KSP bezieht. Das geschieht über die CA-Registry. Danach startest du den Dienst und prüfst sofort, ob die CA überhaupt wieder sauber hochkommt.
|
PowerShell # Provider der CA auf den HSM-KSP umstellen certutil -setreg CA\\CSP\\Provider "<HSM-KSP-Name>" certutil -setreg CA\\CSP\\ProviderType 0
# CA-Dienst wieder starten Start-Service CertSvc
# Kommt die CA sauber hoch? Status und Schluesselzugriff pruefen certutil -ping |
|---|
|
Warnung · Klassische Falle Den alten Software-Schlüssel löschen, bevor verifiziert ist, dass die CA aus dem HSM heraus tatsächlich signieren kann. Wenn der KSP falsch angebunden ist, das HSM-Partitionspasswort nicht passt oder der Import unvollständig war, hängt deine CA – und ohne den alten Schlüssel kommst du nicht mehr zurück. Die Reihenfolge ist heilig: erst aus dem HSM ein echtes Testzertifikat ausstellen, dann erst den Software-Schlüssel entfernen. |
|---|
5. Verifizieren – und erst dann den Software-Schlüssel löschen
Der wichtigste Schritt überhaupt. Du stellst ein echtes Testzertifikat aus und prüfst, dass die Signatur aus dem HSM kommt und die Kette intakt ist. Erst wenn das nachweislich funktioniert, entfernst du den importierten Software-Schlüssel aus dem Betriebssystem – damit er nicht mehr Teil künftiger System-Backups ist und der einzige verbleibende Schlüssel im HSM liegt.
|
PowerShell # Testzertifikat ausstellen lassen und Kette pruefen certutil -ping certreq -submit C:\\Temp\\test.req
# Liegt der aktive CA-Schluessel jetzt wirklich im HSM-Container? certutil -store My
# ERST JETZT: importierten Software-Schluessel aus dem CSP entfernen # (nach dokumentierter, erfolgreicher Verifikation) certutil -delkey "<alter-Software-Containername>" |
|---|
|
Praxis-Tipp · Aus dem Beratungsalltag Plane das HSM-Backup gleich mit ein – ein einzelnes HSM ist ein Single Point of Failure für deine gesamte CA. Entweder ein zweites Gerät mit Schlüssel-Cloning oder ein verschlüsselter Export im Herstellerverfahren, sicher verwahrt. Und dokumentiere jeden Schritt mit Zeitstempel und Verantwortlichem. Genau diese Lückenlosigkeit ist es, die ein Audit sehen will – und die dir CertBinder als Audit-Begleiter automatisiert festhält, statt dass du sie händisch im Protokoll nachpflegst. |
|---|
Praxis-Beispiel: Nordlicht Energiegenossenschaft eG
Die Nordlicht Energiegenossenschaft eG betrieb seit Jahren eine Software-CA, die im Zuge der NIS2-Betroffenheit plötzlich unter Audit-Beobachtung stand. Der Prüfer bemängelte den ungeschützten privaten Schlüssel im Betriebssystem – ein klassisches Finding, das vor der Re-Zertifizierung weg musste, ohne dass die zahlreichen bereits ausgerollten Maschinen- und Nutzerzertifikate ungültig werden durften.
Die Maßnahme: Migration per Schlüsselimport (Weg A) auf ein neu beschafftes HSM. Komplettes CA-Backup, Import des Schlüssels ins HSM, Umstellung des Providers, ein dokumentiertes Testzertifikat zur Verifikation – und erst danach das Löschen des Software-Schlüssels. Das Wartungsfenster betrug keine zwei Stunden, weil die Vertrauenskette unangetastet blieb.
Das Ergebnis: Der private Schlüssel lag nun manipulationssicher im HSM, keine einzige Client-Konfiguration musste angefasst werden, und das Audit-Finding war mit lückenlosem Protokoll geschlossen. Die Re-Zertifizierung lief ohne weitere Nachfragen zum Schlüsselschutz durch.
Verwandte Themen
Häufige Fragen (FAQ)
Bricht meine Vertrauenskette, wenn ich auf ein HSM migriere?
Beim Schlüsselimport (Weg A) nicht. Du importierst den bestehenden privaten Schlüssel ins HSM und stellst nur den Provider um – die CA, ihr Zertifikat und alle bereits ausgestellten Zertifikate bleiben unverändert gültig. Nur wenn du bewusst eine neue CA aufbaust (Weg B), müssen Clients neu enrollen.
Wann sollte ich den alten Software-Schlüssel löschen?
Ausschließlich nach erfolgreicher, dokumentierter Verifikation. Stell aus dem HSM heraus ein echtes Testzertifikat aus und prüfe, dass die Signatur und die Kette stimmen. Erst dann entfernst du den importierten Software-Schlüssel – vorher ist er dein einziges Sicherheitsnetz, falls die HSM-Anbindung klemmt.
Wie lange dauert so eine Migration?
Beim Import-Weg liegt das eigentliche Wartungsfenster meist unter zwei Stunden, weil die CA nur kurz für den Provider-Wechsel stoppt. Vorbereitung, Backup, HSM-Installation und Tests kommen davor und lassen sich größtenteils ohne Ausfall erledigen.
Brauche ich ein zweites HSM?
Für den Produktivbetrieb dringend zu empfehlen. Ein einzelnes HSM ist ein Single Point of Failure für die gesamte CA – geht es kaputt, ist ohne Backup auch der Schlüssel weg. Entweder ein zweites Gerät mit Schlüssel-Cloning oder ein verschlüsselter Export im Herstellerverfahren, sicher verwahrt und einmal real zurückgespielt.
Kann ich während der Migration weiter Zertifikate ausstellen?
Während des eigentlichen Provider-Wechsels nicht – dafür stoppt der CA-Dienst kurz. Davor und danach läuft die Ausstellung normal weiter. Plane den Wechsel deshalb in ein Wartungsfenster mit geringer Enrollment-Last, etwa außerhalb der Kernarbeitszeit.
Was hat CertBinder mit der HSM-Migration zu tun?
CertBinder begleitet die Migration auf der Nachweis-Seite: Es protokolliert lückenlos, welche Schlüssel wann wohin gewandert sind und welche Zertifikate betroffen waren – genau die Dokumentation, die ein Audit sehen will. Die technische Umstellung machst du in ADCS, die revisionssichere Beweiskette liefert CertBinder dazu.
Nächste Schritte mit boddenberg.de
Eine Schlüsselmigration ist einer der wenigen Eingriffe, bei denen ein Fehler die komplette CA kosten kann – hier zahlt sich Erfahrung unmittelbar aus. Drei Wege, wie ich dich unterstütze:
Schick mir eine kurze Mail mit deinem Szenario – aktueller Provider, geplantes HSM, Audit-Druck ja oder nein – und du bekommst innerhalb eines Werktags eine Einschätzung zum sinnvollsten Migrationsweg.
Kontakt: Uli Boddenberg · boddenberg.de · Dortmund