Ihr Leitfaden zur PKI-Migration

Die meisten PKI-Migrationen scheitern nicht an der Kryptografie. Sie scheitern vielmehr, weil abhängige Anwendungen vergessen wurden, ein Rollback-Plan fehlte oder die Zeit vor dem Ablauf eines Root-Zertifikats während der Migration nicht ausreichte. Laut dem CyberArk-Bericht „State of Machine Identity Security 2025“ hatten über 70 % der Unternehmen im vergangenen Jahr mindestens einen zertifikatsbedingten Ausfall. Die vom CA/Browser Forum angekündigten Verkürzungen der Zertifikatslebensdauer werden dieses Problem für alle, die Migrationen noch manuell durchführen, weiter verschärfen.

Dieser Leitfaden erläutert, was eine PKI-Migration genau beinhaltet, wie man sich darauf vorbereitet, welche der vier gängigen Migrationsstrategien zu Ihrer Situation passt, welche Fallstricke die meisten Projekte zum Scheitern bringen und wie die Automatisierung die Berechnungen verändert.

Wichtige Erkenntnisse

• Bei der PKI-Migration werden Zertifizierungsstellen, Schlüssel und Zertifikate in eine neue Umgebung verlagert, wobei die Vertrauenskette erhalten bleibt; ein fehlerhaftes Stamm- oder Zwischenzertifikat während der Migration kann alle Anwendungen lahmlegen, die davon abhängen.
• Ab dem 15. März 2026 ist die Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate gemäß CA/Browser Forum Ballot SC-081v3 auf 200 Tage begrenzt, sinkt im Jahr 2027 auf 100 Tage und im Jahr 2029 auf 47 Tage, was manuelle Migrationsprozesse für öffentlich zugängliche Zertifikate unhaltbar macht.
• Es gibt vier Migrationsstrategien: Lift-and-Shift, Rehosting, Infrastruktur-Upgrade und Systemneugestaltung. Jede Strategie wägt die Geschwindigkeit gegen den Umfang der tatsächlichen Behebung von Problemen in der bestehenden Umgebung ab.
• Eine vollständige Zertifikats- und CA-Inventarisierung, ein dokumentierter Rollback-Plan und eine stufenweise Durchführung sind die drei Kontrollmechanismen, die Migrationsausfälle am zuverlässigsten verhindern.
• Laut dem State of Machine Identity Report von Keyfactor nutzen Unternehmen im Durchschnitt 9 verschiedene PKI- und CA-Lösungen, wobei 37 % mehr als 10 einsetzen. Aus diesem Grund ist die Inventarisierung in der Regel die längste Phase jeder Migration.

Die Public-Key-Infrastruktur (PKI) sichert und authentifiziert den Datenverkehr zwischen Clients und Servern, am deutlichsten sichtbar durch SSL/TLS . Wenn sich ein Client mit einem Server verbindet, prüft er dessen Zertifikat anhand einer vertrauenswürdigen Zertifizierungsstelle (CA), bevor er Daten verschlüsselt. Genau diese Vertrauensbeziehung birgt die PKI-Migration in Gefahr, wenn sie unachtsam durchgeführt wird: Wird eine CA verschoben oder neu ausgestellt, ohne die Vertrauenskette zu wahren, können alle zugehörigen Zertifikate sofort ihre Gültigkeit verlieren.

Deshalb werden PKI-Migrationen in Phasen geplant und nicht als ein einziger Umstellungsvorgang durchgeführt, und deshalb lohnt sich die unten beschriebene Inventarisierungsphase trotz des Zeitaufwands.

Was die PKI-Migration beinhaltet

Bei einer PKI-Migration werden vier Kategorien von Komponenten verschoben: Zertifizierungsstellen, Registrierungsstellen, digitale Zertifikate und die dazugehörigen Schlüssel sowie alle Systeme, die so konfiguriert sind, dass sie diesen vertrauen oder von ihnen abhängig sind.

Die Kernkomponenten, die Sie migrieren

Zertifizierungsstelle (CA): Der Vertrauensanker der PKI. Eine CA stellt digitale Zertifikate aus , verwaltet Zertifikatssperrlisten (CRLs) und bürgt für die Identität jeder Entität, die ein Zertifikat von ihr besitzt. Jedes Gerät oder jede Anwendung, die der CA vertraut, vertraut implizit auch allem, was die CA signiert. Daher birgt die Migration einer CA das höchste Risiko aller Schritte.

Registrierungsstelle (RA): Die Vermittlerstelle, die Zertifikatsignierungsanfragen (CSRs) entgegennimmt und prüft , bevor genehmigte Anfragen an die Zertifizierungsstelle (CA) weitergeleitet werden. RAs sind aus Sicherheits- und Zugriffskontrollgründen in der Regel von der CA getrennt, und hier legen die meisten Organisationen die Geschäftsregeln fest, wer welche Art von Zertifikat beantragen darf.

Digitale Zertifikate: Signierte Dokumente, die einen öffentlichen Schlüssel an eine Identität binden, sei es ein vollqualifizierter Domänenname (FQDN), eine IP-Adresse, ein Benutzer oder ein Gerät. Das Subjektfeld des Zertifikats wird von Anwendungen bei der Authentifizierung geprüft. Daher müssen Subjekt- und SAN-Werte (Subject Alternative Name) fehlerfrei übertragen werden, da sonst die Validierung fehlschlägt.

Hardware-Sicherheitsmodul (HSM): HSMs generieren und speichern die privaten Schlüssel hinter jeder Zertifizierungsstelle (CA) und häufig auch wichtige Endbenutzerzertifikate in manipulationssicherer Hardware. Eine PKI ist nur so vertrauenswürdig wie der zugrunde liegende Schlüsselschutz. Daher ist die HSM-Migration (Übertragung von Schlüsselmaterial zwischen verschiedenen Herstellern oder Hardwaregenerationen) eines der sensibelsten Teilprojekte innerhalb einer umfassenderen PKI-Migration.

Verzeichnisdienste: Zentrale Speicherorte wie Active Directory Certificate Services (AD CS) , die Identitäts- und Zugriffsinformationen speichern und häufig Zertifikate direkt an in die Domäne eingebundene Geräte und Benutzer ausstellen. AD CS ist seit 2008 eine Windows Server-Rolle und nach wie vor die am häufigsten verwendete private Zertifizierungsstelle in Unternehmensumgebungen. Daher handelt es sich bei vielen PKI-Migrationen im Grunde um AD CS-Migrationen.

Die vier Migrationsphasen

Unabhängig davon, ob Sie eine Plattform für das Zertifikatslebenszyklusmanagement (CLM) betreiben oder alles manuell verwalten, durchläuft jede PKI-Migration die gleichen vier Phasen:

1. Erstellen Sie den Lagerbestand. Katalogisieren Sie jedes Zertifikat, jede Zertifizierungsstelle und jeden Schlüssel in der aktuellen Umgebung.
2. Übertragen Sie das Treuhandmaterial. Übertragen Sie Zertifikate, Zertifizierungsstellen und wichtiges Material auf die neue Infrastruktur.
3. Abhängige Systeme neu konfigurieren. Richten Sie jede Anwendung, jeden Server und jeden Dienst auf die neue PKI aus.
4. Testen und überwachen. Prüfen Sie die neue Konfiguration und beobachten Sie sie unter realem Datenverkehr, bevor Sie die alte Konfiguration außer Betrieb nehmen.

Eine CLM-Plattform wie CertSecure Manager verkürzt die erste Phase erheblich, da bereits ein präzises und kontinuierlich aktualisiertes Inventar vorhanden ist und nicht erst von Grund auf neu erstellt werden muss. Ohne eine solche Plattform kann allein die Inventarisierung Wochen dauern, und jedes in dieser Phase übersehene Zertifikat stellt später ein Ausfallrisiko dar.

Zu beachtende Punkte vor der Migration

Aktueller Bestand

Was nicht erfasst wurde, kann nicht migriert werden. Eine vollständige Bestandsaufnahme umfasst drei Zertifikatsstufen sowie alles, was davon abhängt:

• Root-Zertifikate sind die grundlegenden Vertrauensanker der PKI. Wenn ein Stammzertifikat Läuft die Migration ab oder wird sie währenddessen fehlerhaft behandelt, bricht die gesamte darunter liegende Vertrauenskette zusammen.
• Zwischenzertifikate Sie befinden sich zwischen dem Stammzertifikat und dem Endbenutzerzertifikat und delegieren das Vertrauen nach unten.
• Endbenutzerzertifikate Diese Zertifikate werden an die Benutzer, Server, Anwendungen und Geräte ausgegeben, die sie tatsächlich zur Authentifizierung und Verschlüsselung benötigen. Wenn diese Zertifikate ablaufen oder während einer Migration widerrufen werden, ist die Wahrscheinlichkeit am größten, dass es zu einem sichtbaren Ausfall kommt.

Abhängige Systeme sind genauso wichtig wie die Zertifikate selbst. Der Network Device Enrollment Service ( NDES ) und Mobile-Device-Management-Plattformen wie Intune stellen Gerätezertifikate häufig in großen Mengen aus. Daher muss jeder einzelne Integrationspunkt identifiziert und neu konfiguriert werden, nicht nur die Zertifikate selbst. Eine übersehene Abhängigkeit ist die häufigste Ursache für Ausfälle nach der Migration.

Kompatibilität und Standards

Die neue PKI-Umgebung muss mit Ihrer bestehenden Infrastruktur kompatibel sein, nicht nur mit den geplanten Systemen für das nächste Jahr. Einige ältere Anwendungen unterstützen noch immer keine elliptische Kurvenkryptographie (ECC) oder neuere Schlüssellängen. Ein erzwungenes Upgrade ohne vorherige Kompatibilitätsprüfung kann die Authentifizierung von Systemen, die noch die alte Zertifizierungsstelle (CA) verwenden, unbemerkt beeinträchtigen.

Testen Sie alle Abhängigkeiten in der neuen Umgebung vor der Umstellung, nicht danach. Ein während der Tests entdeckter Kompatibilitätsfehler führt zu einer Verzögerung; derselbe Fehler in der Produktionsumgebung führt zu einem Ausfall.

Automatisierung und Skalierbarkeit

Die manuelle Nachverfolgung Hunderter oder Tausender Zertifikate war nie praktikabel und wird von Jahr zu Jahr immer weniger praktikabel. Die Studie „State of Machine Identity“ von Keyfactor ergab, dass Unternehmen durchschnittlich neun verschiedene PKI- und Zertifizierungsstellenlösungen einsetzen, 37 % sogar mehr als zehn. Genau diese Komplexität macht die manuelle Zertifikatsnachverfolgung während einer Migration unmöglich.

Drei Automatisierungskomponenten sind während und nach einer Migration von größter Bedeutung:

• Proaktive Warnungen die Zertifikatsinhaber vor Ablauf des Zertifikats benachrichtigen, nicht erst danach.
• Erneuerungsauslöser die automatisch starten, wenn sich das Ablaufdatum nähert, anstatt davon abhängig zu sein, dass sich jemand an eine Tabelle erinnert.
• API-Integration Dadurch kann eine CLM-Plattform erneuerte Zertifikate direkt in abhängige Systeme übertragen, ohne dass eine manuelle Neuinstallation erforderlich ist.

Dies ist heute wichtiger denn je. Gemäß der Abstimmung SC-081v3 des CA/Browser Forums wurde die Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate zum 15. März 2026 auf maximal 200 Tage reduziert, soll im März 2027 auf 100 Tage sinken und bis März 2029 nur noch 47 Tage betragen. Ein Migrationsplan, der auf jährlichen Erneuerungszyklen basiert, ist daher überholt. Bei jeder Migration sollte eine Erneuerung alle paar Monate, nicht nur einmal jährlich, berücksichtigt werden.

Vorbereitung auf die PKI-Migration

Ein Migrationsplan erfordert eine klare Zuständigkeit für jeden dieser Bereiche, bevor die Arbeiten beginnen, und nicht erst, wenn der erste Ausfall diese Frage aufwirft.

• Inventar der Zertifikate und Zertifizierungsstellen. Listen Sie alle Root-, Zwischen- und Endbenutzerzertifikate zusammen mit Standort, Inhaber und Ablaufdatum auf.
• Richtliniendokumentation. Alle aktuell geltenden Richtlinien für Ausstellung, Widerruf und Verlängerung von Verträgen sollten protokolliert werden, damit die neue Umgebung diese reproduzieren kann, anstatt die Kontrollen stillschweigend zu lockern.
• Vertrauensbeziehungen und Abhängigkeiten. Identifizieren Sie jedes System, jede Anwendung und jeden Dienst, der sich mithilfe der aktuellen PKI authentifiziert oder verschlüsselt.
• Risikoanalyse. Schätzen Sie ein, wo die Migration am ehesten zu Serviceunterbrechungen führen wird, und ordnen Sie diese Risiken nach ihren Auswirkungen auf das Geschäft.
• Rollback-Planung. Dokumentieren Sie genau, wie die alten Zertifikate und Konfigurationen wiederhergestellt werden können, falls die Migration währenddessen fehlschlägt. Dieser Kontrollschritt wird am häufigsten übersehen, ist aber gleichzeitig der wichtigste.
• Datensicherung und Redundanz. Sichern Sie Zertifikate, Schlüssel und Konfigurationen vor, während und nach der Migration, um Single Points of Failure in der neuen Architektur zu vermeiden.

Die vier PKI-Migrationsstrategien

Welche Strategie am besten geeignet ist, hängt davon ab, wie veraltet die aktuelle PKI ist, welche konkreten Geschäftsanforderungen an die Umstellung gestellt werden und wie viel Beeinträchtigung akzeptabel ist. Die folgende Tabelle vergleicht alle vier Strategien; in den nachfolgenden Abschnitten werden die einzelnen Strategien detailliert beschrieben.

Strategie	Was ändert sich	Am besten geeignet für	Relative Komplexität
Heben und Verschieben	Nur Standort; PKI wird unverändert repliziert.	Eine moderne, stabile PKI, die lediglich migriert werden muss (z. B. in die Cloud).	Unterste
Rehosting	Standort plus gezielte Verbesserungen (Skalierbarkeit, Sicherheit, Leistung)	Eine funktionsfähige PKI, die modernisiert werden muss, ohne dass eine vollständige Neufassung der Richtlinien erforderlich ist.	Niedrig bis mäßig
Infrastruktur-Upgrade	Zugrundeliegende Plattform, wobei bestehende Schlüssel und Zertifikate beibehalten werden	Veraltete Technologie mit einem noch gültigen Zertifikatsbestand	Mittel bis hoch
Systemneugestaltung	Alles: neue CA-Hierarchie, neue Schlüssel, neue Zertifikate für jeden Endpunkt	Eine PKI, die kompromittiert, veraltet oder nicht mit den aktuellen Standards konform ist.	Höchste

1. Heben und Verschieben

Die bestehende PKI wird mit minimalen Änderungen an ihrer Struktur und ihren Richtlinien in eine neue Umgebung, beispielsweise ein neues Rechenzentrum oder eine Cloud-Plattform, migriert. Dies funktioniert gut, wenn die aktuelle PKI modern und stabil ist, sich aber am falschen Ort befindet. Für die Migration veralteter Infrastrukturen ist diese Methode ungeeignet, da alle bestehenden Schwachstellen unverändert in die neue Umgebung übernommen werden.

Vorteile: minimale Beeinträchtigung des laufenden Betriebs; die schnellste der vier Strategien.

2. Neuhosting

Beim Rehosting wird die PKI verlagert und gleichzeitig gezielte Verbesserungen vorgenommen, wie z. B. der Wechsel zu einer Cloud-basierten Lösung, die Aufrüstung der Serverhardware oder die Verstärkung der Sicherheitskontrollen. Nutzen Sie diese Option, wenn die aktuelle PKI zwar funktioniert, aber eine bessere Skalierbarkeit, Sicherheit oder Leistung benötigt und Sie die bestehende Richtlinienstruktur weitgehend beibehalten möchten.

Vorteile: Verbessert Skalierbarkeit, Sicherheit oder Leistung ohne vollständige Überarbeitung der Richtlinien; minimale Beeinträchtigung der bestehenden Struktur.

3. Infrastrukturmodernisierung

Diese Strategie ersetzt die zugrundeliegende PKI-Plattform und behält gleichzeitig bestehende kryptografische Objekte bei. Das bedeutet, dass bereits ausgestellte Schlüssel und Zertifikate weiterhin gültig und verwendbar bleiben. Sie eignet sich für Organisationen, deren Technologie veraltet ist, deren Zertifikatsbestand aber noch intakt ist. Diese Strategie wird am häufigsten beim Wechsel von einer veralteten zu einer aktuellen, konformen Plattform eingesetzt.

Kompromiss: Erfordert echte Kompatibilitätstests zwischen der alten und der neuen Infrastruktur, was den Vorgang aufwändiger macht als eine einfache Übertragung.

4. Systemneugestaltung

Eine vollständige Neugestaltung beginnt mit neuen kryptografischen Schlüsseln und endet mit einer neuen CA-Hierarchie; jeder Endpunkt erhält einen neuen Vertrauensanker, neue Schlüssel und neue Zertifikate. Dies ist die richtige Vorgehensweise, wenn die bestehende PKI kompromittiert, stark veraltet oder grundlegend nicht mehr den aktuellen Standards entspricht und auch das Einspielen von Patches keine Lösung bietet.

Abwägungsstrategie: die komplexeste, kostspieligste und zeitaufwändigste der vier Strategien und diejenige, die am stärksten von sorgfältiger Planung abhängt, um längere Ausfallzeiten zu vermeiden.

Entscheidungsbaum: Welche PKI-Migrationsstrategie sollten Sie anwenden?

• Wenn Ihre aktuelle PKI modern und stabil ist und lediglich an einen anderen Standort verlegt werden muss: Lift-and-Shift verwenden.
• Wenn Ihre PKI zwar funktioniert, aber eine bessere Skalierbarkeit, Sicherheit oder Leistung benötigt, ohne dass eine vollständige Richtlinienüberarbeitung erforderlich ist: Rehosting verwenden.
• Wenn Ihre Plattform veraltet ist, Ihr Zertifikatsbestand aber noch gültig und konform ist: ein Infrastruktur-Upgrade durchführen.
• Wenn Ihre PKI kompromittiert, stark veraltet oder nicht mit den aktuellen Standards konform ist: eine vollständige Systemneugestaltung durchführen.

Auswahlkriterien: Die richtige PKI-Migrationsstrategie wählen

Wägen Sie diese Kriterien zusammen mit dem obigen Entscheidungsbaum ab, bevor Sie sich für eine Strategie entscheiden:

• Aktueller PKI-ZustandIst es modern und stabil oder veraltet und nicht konform?
• Gültigkeit des ZertifikatsinventarsSind die bestehenden Schlüssel und Zertifikate noch vertrauenswürdig oder müssen sie neu ausgestellt werden?
• AusfallzeittoleranzWie viel Störung kann der Geschäftsbetrieb während der Umstellung verkraften?
• Anzahl abhängiger SystemeWie viele Anwendungen, Geräte und Dienste vertrauen der aktuellen PKI?
• Compliance-AnforderungenMuss die Zielumgebung Standards erfüllen, die die aktuelle nicht erfüllt?
• Verfügbare FachkräfteKann Ihr Team eine vollständige Neugestaltung durchführen, oder ist angesichts der Personalsituation eine Strategie mit weniger Eingriffen realistischer?

Vor- und Nachteile der einzelnen PKI-Migrationsstrategien

Strategie	Vorteile	Nachteile
Heben und Verschieben	Schnellste Option; minimale Beeinträchtigung des laufenden Betriebs	Überträgt alle bestehenden Schwächen der alten PKI in die neue Umgebung
Rehosting	Verbessert Skalierbarkeit, Sicherheit oder Leistung ohne vollständige Richtlinienüberarbeitung.	Es bedarf weiterhin gezielter Infrastruktur- und Sicherheitsmaßnahmen, die über eine einfache Übertragung hinausgehen.
Infrastruktur-Upgrade	Bestehende Schlüssel und Zertifikate bleiben gültig, eine vollständige Neuausstellung wird vermieden.	Erfordert echte Kompatibilitätstests zwischen bestehender und neuer Infrastruktur
Systemneugestaltung	Behebt eine kompromittierte, veraltete oder nicht konforme PKI an der Wurzel.	Die komplexeste, kostspieligste und zeitaufwändigste der vier Strategien; höchstes Risiko längerer Ausfallzeiten

Häufige Fallstricke bei der PKI-Migration

Den Umfang unterschätzen

PKI-Migrationen betreffen jedes System, das der PKI vertraut, nicht nur die Zertifikate selbst. Organisationen, die lediglich die Migration von Zertifikaten planen und dabei Schlüsselverwaltungssysteme, Verzeichnisdienstintegrationen, VPNs und interne Anwendungen außer Acht lassen, stoßen regelmäßig auf Ausfälle aufgrund von Abhängigkeiten, die im Vorfeld nicht berücksichtigt wurden.

Datenverlust und ungeplante Ausfallzeiten

Werden vor der Migration keine Backups erstellt, besteht die Gefahr, dass Zertifikate, Schlüssel und Protokolle verloren gehen, falls während des Prozesses etwas schiefgeht. Fehlende oder unzureichende Tests bergen das Risiko von Ausfallzeiten, die den Geschäftsbetrieb stören. Und das Auslassen von Kompatibilitätsprüfungen mit vorhandenen Hardware-Sicherheitsmodulen (HSMs) und Anwendungen birgt beide Risiken gleichzeitig.

Sicherheitslücken während und nach der Migration

Fehlkonfigurationen und vergessene Einstellungen sind eine häufige Ursache für neue Sicherheitslücken, die durch die Migration selbst entstehen, nicht durch die zu migrierenden Systeme. Nicht erneuerte Zertifikate oder verschobene Schlüsselrotationen, bis die Migration abgeschlossen ist, schwächen die Sicherheitslage genau dann, wenn sie am stärksten sein muss.

Vertrauensbrüche

Beschädigte Zertifikate, Schlüssel oder CRL-Daten während der Übertragung können weit über die PKI hinausgehende Ausfälle verursachen. Jede Unterbrechung der Vertrauenskette während der Migration kann nachgelagerte Zertifikate ungültig machen – genau das Ausfallszenario, das ein Rollback-Plan verhindern soll.

Best Practices für die PKI-Migration

1. Zuerst prüfen und planen. Führen Sie ein vollständiges Audit der bestehenden PKI durch, dokumentieren Sie jede Abhängigkeit und erstellen Sie einen detaillierten Migrationsplan, bevor Sie die Produktionsumgebung anfassen.
2. Migration in Phasen. Durch die phasenweise Migration wird der Explosionsradius verringert und das Team erhält Zeit, Probleme zu erkennen und zu beheben, bevor sie sich verschlimmern.
3. Testen Sie in einer Nicht-Produktionsumgebung. Simulieren Sie die Migration zunächst in einer Testumgebung, um Kompatibilitäts- und Konfigurationsprobleme aufzudecken, bevor sie die Produktionsumgebung erreichen.
4. Vor jeder Phase ein Backup erstellen. Sichern Sie regelmäßig Zertifikate, Schlüssel und Konfigurationen und halten Sie einen Wiederherstellungsplan bereit, falls eine Phase fehlschlägt.

Unsere Einschätzung: Wo Migrationen tatsächlich schiefgehen

In unseren Beratungsprojekten scheitern Migrationen, die auf Probleme stoßen, fast nie an der Kryptografie, sondern an der Bestandsaufnahme. Teams, die auf eine ordnungsgemäße Zertifikats- und Abhängigkeitsprüfung verzichten, entdecken regelmäßig mitten in der Migration eine Anwendung oder ein Gerät, dessen Existenz sie vergessen hatten – und diese Entdeckung erfolgt meist während eines Produktionsausfalls und nicht in der Planungsphase.

Der zweithäufigste Fehlerpunkt ist die fehlende Rollback-Planung. Unternehmen planen den weiteren Weg sorgfältig und behandeln den Rollback-Plan erst dann, wenn sie ihn nachts um 2 Uhr benötigen, die Vertrauenskette unterbrochen ist und es keinen sauberen Weg zurück gibt. Da die Gültigkeitsdauer von Zertifikaten unter die 200-Tage-Grenze des CA/Browser Forums fällt (bis 2029 nur noch 47 Tage), steigt die Anzahl der Erneuerungen bei Migrationen stetig an. Dadurch werden diese beiden Schwachstellen heute deutlich teurer, wenn sie unbeachtet bleiben, als noch vor ein oder zwei Jahren.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting entwirft und migriert PKI-Infrastrukturen, die auf die spezifischen Sicherheits- und Compliance-Anforderungen jeder Organisation abgestimmt sind, unterstützt durch praktische Erfahrung in der PKI-Beratung und -Dienstleistungen für jede der oben genannten Migrationsstrategien.

Für Organisationen, die das PKI-Migrationsrisiko direkt reduzieren möchten, bietet CertSecure Manager , die Zertifikatslebenszyklus-Managementplattform von EC, jetzt in Version 3.3, Folgendes:

• Migration einer öffentlichen Zertifizierungsstelle mit einem Klick das Zertifikate zwischen öffentlichen Zertifizierungsstellen überträgt, ohne dass die Registrierung von Grund auf neu durchgeführt werden muss.
• Erweiterte Entdeckung Über AWS, den zentralen Zertifikatsspeicher von IIS, Container und Tresore hinweg werden die blinden Flecken im Inventar geschlossen, die während der Migration zu Zertifikatsausfällen führen können.
• Visualisierung der ZertifikatsvertrauensketteAdministratoren können so die vollständige Beziehungskette direkt in der Benutzeroberfläche anzeigen und herunterladen, was die Untersuchungszeit verkürzt, falls während der Migration ein Problem mit der Vertrauenskette auftritt.
• Massenwiderruf und Massenübertragung des EigentumsDadurch wird der manuelle Aufwand reduziert, wenn sich die Zertifikatsinhaberschaft im Rahmen einer Organisations- oder Infrastrukturveränderung ändert.
• End-to-End-Automatisierung der Vertragserneuerung Das hält mit den immer kürzer werdenden Gültigkeitszeiträumen des CA/Browser-Forums Schritt, sodass kein Zertifikat mitten in der Migration abläuft, weil kein manueller Erneuerungsschritt erforderlich ist.

Mit PKI-as-a-Service können Unternehmen auch die operative Last der Führung der Zielumgebung vollständig abgeben, anstatt auf eine Infrastruktur zu migrieren, die sie dann selbst besetzen und warten müssen.

Häufig gestellte Fragen

Was ist PKI-Migration?
Die PKI-Migration ist der Prozess, bei dem die Zertifizierungsstellen, Schlüssel und Zertifikate einer Public-Key-Infrastruktur von einer Umgebung in eine andere, beispielsweise von einem lokalen Rechenzentrum in die Cloud, verschoben werden, wobei die Vertrauenskette, auf der die bestehenden Zertifikate beruhen, erhalten bleibt.

Wie lange dauert eine PKI-Migration?
Die Zeitpläne variieren stark je nach Umfang. Die Migration einer gut dokumentierten PKI kann Wochen dauern; eine vollständige Systemneugestaltung in einer großen, schlecht inventarisierten Unternehmensumgebung kann viele Monate in Anspruch nehmen, wobei die Inventarisierung und die Abbildung von Abhängigkeiten typischerweise den größten Teil dieser Zeit beanspruchen.

Was ist das größte Risiko bei einer PKI-Migration?
Die Vertrauenskette wird unterbrochen, üblicherweise durch fehlerhafte Behandlung eines Stamm- oder Zwischenzertifikats oder durch das Übersehen eines abhängigen Systems bei der Inventarisierung. Beides kann dazu führen, dass Zertifikate in der gesamten Umgebung sofort nicht mehr validiert werden.

Welche PKI-Migrationsstrategie sollte ich verwenden?
Verwenden Sie Lift-and-Shift, wenn die aktuelle PKI modern ist und lediglich verlagert werden muss, Rehosting, wenn gezielte Verbesserungen erforderlich sind, ein Infrastruktur-Upgrade, wenn die Plattform veraltet ist, das Zertifikatsinventar aber noch gültig ist, und eine vollständige Systemneugestaltung, wenn die PKI kompromittiert ist oder nicht den aktuellen Standards entspricht.

Benötige ich eine Lösung für das Zertifikatslebenszyklusmanagement (CLM), um eine PKI zu migrieren?
Nein, aber der Aufwand ändert sich dadurch erheblich. Ohne eine CLM-Plattform müssen Teams das Zertifikats- und CA-Inventar manuell von Grund auf neu erstellen. Eine CLM-Lösung pflegt dieses Inventar kontinuierlich und eliminiert so den größten und risikoreichsten manuellen Schritt im Prozess.

Wie wirkt sich die kürzere Gültigkeitsdauer des Zertifikats des CA/Browser Forums auf die PKI-Migration aus?
Ab dem 15. März 2026 ist die Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate gemäß Abstimmung SC-081v3 auf 200 Tage begrenzt. Diese sinkt 2027 auf 100 Tage und 2029 auf 47 Tage. Migrationen, die von jährlichen Erneuerungszyklen ausgehen, sind daher überholt. Jeder PKI-Migrationsplan für öffentlich zugängliche Zertifikate muss die automatische Erneuerung von Anfang an integrieren und darf nicht nachträglich hinzugefügt werden.

Kann ich eine PKI ohne Ausfallzeiten migrieren?
Durch sorgfältige Phasenplanung, Redundanz während der Übergangsphase und einen getesteten Rollback-Plan lässt sich bei den meisten Migrationen eine unterbrechungsfreie Migration erreichen. Dies erfordert jedoch mehr Vorplanungszeit als ein einmaliger Umstieg. Übereilte Migrationen führen deutlich häufiger zu Ausfällen, die ein phasenweiser Ansatz eigentlich vermeiden soll.

Worin besteht der Unterschied zwischen einem Rehosting und einem Infrastruktur-Upgrade?
Beim Rehosting wird die PKI verlagert und gezielte Verbesserungen vorgenommen, wobei die meisten bestehenden Richtlinien erhalten bleiben. Ein Infrastruktur-Upgrade ersetzt die zugrunde liegende Plattform vollständig, bewahrt aber bestehende Schlüssel und Zertifikate. Rehosting ist die weniger aufwändige Option; ein Infrastruktur-Upgrade bedeutet eine größere technologische Umstellung mit geringeren Richtlinienänderungen.

Was passiert, wenn ein Stammzertifikat während der Migration abläuft?
Alle unter dieser Stammzertifizierungsstelle ausgestellten Zertifikate verlieren ihre Gültigkeit, was zu einem gleichzeitigen, unternehmensweiten Ausfall aller Anwendungen und Dienste führt, die von dieser Zertifikatskette abhängen. Aus diesem Grund wird die Verwaltung von Stammzertifikaten bei der Migrationsplanung besonders sorgfältig geprüft, und es gibt spezielle Rollback-Pläne, um dieses Szenario schnellstmöglich rückgängig zu machen.

Welche Rolle spielt AD CS bei der PKI-Migration?
Active Directory-Zertifikatdienste (AD CS) ist die am häufigsten verwendete private Zertifizierungsstelle in Unternehmensumgebungen, daher entsprechen viele PKI-Migrationen im Grunde AD CS-Migrationen. Da AD CS Zertifikate direkt an in die Domäne eingebundene Geräte und Benutzer ausstellt, erfordert die Migration eine sorgfältige Abstimmung mit Active Directory selbst, nicht nur mit dem Zertifikatsspeicher.

Fazit

Die Migration einer PKI ist komplex, aber mit der richtigen Vorbereitung ist diese Komplexität beherrschbar: eine vollständige Bestandsaufnahme, eine auf den aktuellen Zustand der Umgebung abgestimmte Strategie, ein getesteter Rückrufplan und eine Automatisierung der Erneuerungen, damit die immer kürzer werdenden Zertifikatslebensdauern nicht jede Migration zu einem Wettlauf gegen die Ablaufdaten machen.

Eine erfolgreiche Migration bewirkt mehr als nur die Verlagerung der Infrastruktur. Sie beseitigt die Compliance-Lücken und den technischen Schuldenberg, die die Migration überhaupt erst notwendig gemacht haben, und versetzt das Unternehmen in eine bessere Position für die künftigen Zertifikatslaufzeiten und kryptografischen Standards.