Was passiert, wenn der Private Key verloren geht?

Geht der Private Key verloren, wird das zugehörige SSL-Zertifikat unbrauchbar — ohne den passenden Key kann der Server keine TLS-Verbindung aufbauen. Das Zertifikat selbst bleibt zwar formal gültig, ist aber wertlos. Die Lösung ist ein Re-Issue (kostenfreie Neuausstellung mit neuem Schlüsselpaar) und in der Regel zusätzlich die Sperrung des alten Zertifikats.

Der Private Key existiert ausschließlich auf der Server- oder Client-Seite. Die Zertifizierungsstelle (CA) sieht ihn nie, kennt ihn nicht und kann ihn nicht wiederherstellen. Wer den Key verliert, kann sich also nicht an die CA wenden, um eine Kopie zu erhalten — diese existiert nirgendwo.

Welche Folgen ein Verlust hat:

Zwei Szenarien lassen sich unterscheiden:

Szenario 1: Key ist nur verloren, nicht kompromittiert. Beispiel: Server wurde plattgemacht, das Backup enthielt den Key nicht. In diesem Fall reicht ein Re-Issue. Eine Sperrung ist nicht zwingend nötig, weil der Key niemandem in die Hände gefallen ist — wir empfehlen sie aber trotzdem, um zwei gültige Zertifikate für dieselbe Domain zu vermeiden.

Szenario 2: Key ist kompromittiert. Beispiel: unverschlüsseltes Backup wurde geleakt, ehemaliger Mitarbeiter mit Zugriff, gestohlener Server, versehentliches Einchecken in ein öffentliches Git-Repository. Hier ist die Sperrung zwingend. Das CA/Browser-Forum verlangt, dass die CA das Zertifikat innerhalb von 24 Stunden nach Kenntnis der Kompromittierung widerruft.

So gehen Sie bei Verlust oder Kompromittierung vor:

1. Neues Schlüsselpaar erzeugen auf einem sicheren System: openssl req -new -newkey rsa:2048 -nodes -keyout meine-domain.key -out meine-domain.csr
2. Re-Issue im Kundenbereich beantragen und den neuen CSR einreichen. Domain-Validierung wird je nach CA und Alter der vorigen Validierung neu angefordert.
3. Neues Zertifikat installieren und parallel zum alten testen, dann umschalten.
4. Altes Zertifikat sperren lassen (Revocation) — bei Kompromittierung sofort, sonst nach erfolgreicher Umstellung.
5. Logs prüfen bei Kompromittierung: Wurde der alte Key in der Zwischenzeit für nicht autorisierte Verbindungen genutzt? Welche Daten könnten betroffen sein?

Was Sie sofort tun sollten, wenn der Key öffentlich geleakt sein könnte:

• Git-Historie bereinigen reicht nicht — der Key gilt als kompromittiert, sobald er irgendwo öffentlich war, auch kurzzeitig.
• Sperrung sofort auslösen, bevor Sie Re-Issue oder andere Schritte angehen.
• Mailserver, VPN, Code-Signing und andere Dienste prüfen, die ggf. denselben Key nutzen — und diese ebenfalls neu ausstatten.
• DSGVO-Meldepflicht prüfen: Wenn personenbezogene Daten betroffen sein könnten, kann eine Meldung nach Art. 33 DSGVO innerhalb von 72 Stunden nötig sein.

Vorbeugen ist die deutlich günstigere Option:

• Verschlüsselte Backups des Private Keys an einem zweiten, getrennten Ort — nicht auf demselben Server.
• Klare Dateinamen-Konvention mit Domain und Datum, damit der richtige Key bei mehreren parallelen Zertifikaten eindeutig zuordenbar ist.
• Zugriff einschränken: Dateirechte 600 auf Linux, ACLs auf Windows, kein Lese-Zugriff für Webserver-Prozesse oder Anwendungen, die ihn nicht brauchen.
• Niemals in Code-Repositories einchecken — auch nicht in private. Pre-Commit-Hooks oder Secret-Scanner helfen, das zu erzwingen.
• Schlüsselrotation bei jeder Verlängerung — neuer CSR, neues Schlüsselpaar. Verkleinert das Zeitfenster, in dem ein einzelner Key kompromittiert werden kann.
• Hardware Security Module (HSM) für besonders sensible Setups: Der Private Key verlässt das HSM nie, Verschlüsselung erfolgt direkt im Modul.

Bei Hosting-Providern und Managed-Plattformen liegt der Key oft in der Plattform selbst. Dort kümmert sich der Anbieter um Backup und Schutz — der Verlust durch eigene Fehler ist dann ausgeschlossen, dafür haben Sie keinen direkten Zugriff auf den Key, was bei Migrationen wiederum einschränkend sein kann.