Ihre Zertifikate laufen ab. Ihre Vertrauensarchitektur bleibt.

Ausgabe 10 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für Infrastruktur, Identitäts- und Zugriffsmanagement und alle, die eine Public-Key-Infrastruktur verantworten.

„Zertifikate tauschen wir ohnehin alle zwei Jahre, das ist Routine.“ Stimmt, für die Zertifikate. Die Stammzertifizierungsstelle, die sie ausstellt, stammt aus dem Jahr 2015, ist bis 2035 gültig und hat einen RSA-Schlüssel. Das Hardware-Sicherheitsmodul, in dem dieser Schlüssel liegt, kennt kein Post-Quanten-Verfahren. Und die Geräte, die den Zertifikaten vertrauen, wissen nicht, wie eine ML-DSA-Signatur aussieht.

In diesem Beitrag: Was eine PKI ist · Warum ein neues Zertifikat nicht reicht · Schlüsselaustausch zuerst, Signaturen planen · Größe ist ein Architekturthema · Drei Richtungen der Abhängigkeit · Beispiel · Was Sie verlangen sollten · Was sich ändert · Die Frage an Ihren Lieferanten · Anhang: Schema und Prüfliste

Eine Public-Key-Infrastruktur ist kein Zertifikat und kein Server. Die EU-Roadmap zur Post-Quanten-Kryptografie definiert sie knapp als Rahmen zum Ausstellen, Pflegen und Widerrufen von Zertifikaten. In der Praxis besteht sie aus mehreren Schichten, die unterschiedlich lange leben:

• Vertrauensanker: das Stammzertifikat, das in Betriebssystemen, Browsern, Geräten und Anwendungen hinterlegt ist. Lebensdauer oft 15 bis 25 Jahre.
• Zwischenzertifizierungsstellen: stellen im Alltag aus. Lebensdauer meist 5 bis 10 Jahre.
• Endzertifikate: für Server, Benutzer, Geräte, Code. Lebensdauer Monate bis wenige Jahre.
• Sperrinformationen: Sperrlisten und Online-Statusabfragen, selbst signiert.
• Schlüsselverwahrung: Hardware-Sicherheitsmodule, Smartcards, Token.
• Registrierung und Verteilung: Verfahren wie SCEP, EST, ACME, CMP oder automatische Registrierung im Verzeichnisdienst.
• Prüfende Seite: jede Software, die eine Signatur oder Zertifikatskette verifiziert.

Ein Zertifikatswechsel berührt eine Schicht. Eine Post-Quanten-Umstellung berührt alle. Die Verschlüsselung der Verbindungen ist Thema der nächsten Ausgabe; sie hängt mit der PKI zusammen, ist aber etwas anderes.

Ein Zertifikat mit ML-DSA-Signatur nützt nur, wenn jede Schicht mitkommt:

• Die prüfende Seite muss das Verfahren kennen. Die IETF hat die Verwendung von ML-DSA in X.509-Zertifikaten im Oktober 2025 als RFC 9881 standardisiert. Ob eine bestimmte Anwendung, ein Gerät oder eine Bibliothek das unterstützt, ist eine Frage der Version.
• Die ausstellende Stelle muss mit dem neuen Verfahren signieren können, und ihr Schlüssel muss in einem Modul liegen, das es beherrscht. Bei Hardware-Sicherheitsmodulen ist das eine Frage von Firmware, Zertifizierung und manchmal Austausch.
• Der Vertrauensanker muss auf allen prüfenden Systemen ankommen. Bei Servern ist das eine Verteilung, bei Geräten im Feld unter Umständen ein Firmware-Update.
• Die Registrierung muss neue Schlüsseltypen anfordern und übermitteln können.

Daraus folgt eine Reihenfolge, die im Projektplan leicht verkehrt herum steht: Die prüfende Seite muss zuerst bereit sein. Wer Server auf neue Zertifikate umstellt, bevor alle Clients sie prüfen können, schaltet Clients ab.

In der Praxis entstehen deshalb parallele Hierarchien: Eine neue, Post-Quanten-fähige Hierarchie wird neben der bestehenden aufgebaut und schrittweise eingeführt. Verfahren, die klassische und Post-Quanten-Signaturen in einem Zertifikat kombinieren, werden in der IETF erarbeitet und können den Übergang erleichtern. Für öffentlich vertrauenswürdige Webserver-Zertifikate sind Post-Quanten-Signaturen nach unserem Kenntnisstand im April 2026 noch nicht allgemein verfügbar.

Eine wichtige Entlastung: Nicht alles eilt gleich. Die Gefahr „heute mitschneiden, später entschlüsseln“ betrifft den Schlüsselaustausch. Er lässt sich hybrid umstellen, ohne neue Zertifikate: Ein TLS-Handshake mit hybridem Schlüsselaustausch funktioniert mit einem klassischen Serverzertifikat.

Die Authentisierung im Handshake kann ein Angreifer dagegen nur in Echtzeit fälschen, nicht rückwirkend. Solange es keinen Quantenrechner gibt, schützt ein klassisches Zertifikat die Verbindung von heute.

Das gilt nicht für Signaturen, die lange gültig bleiben müssen:

• Vertrauensanker, die bis 2035 und länger in Geräten stecken;
• Firmware- und Software-Signaturen, auf deren Echtheit sich Geräte jahrzehntelang verlassen; die EU-Roadmap empfiehlt hier ausdrücklich, Update-Mechanismen mit quantensicheren Signaturen auszustatten;
• Dokumentsignaturen mit langer Beweisfunktion.

Hier muss die Planung jetzt beginnen, weil die Umstellung lange dauert, nicht weil der Angriff heute stattfindet.

Post-Quanten-Signaturen sind deutlich größer als die heutigen. Nach FIPS 204:

Für einen Server mit Breitbandanbindung ist das kaum spürbar. Für eine Smartcard mit begrenztem Speicher, ein Funkmodul mit kleinen Paketen, einen Protokollkopf mit fester Größe oder eine Zertifikatskette mit vier Ebenen kann es entscheidend sein. Welche Geräte das betrifft, gehört in die Planung, bevor ein Verfahren festgelegt wird.

In einer Lieferbeziehung hängt eine PKI in drei Richtungen:

• Sie stellen aus, der Lieferant vertraut: Zertifikate für Lieferantenzugänge, VPN-Clients der Servicetechniker, Clientzertifikate für Ihr Portal. Ihre Umstellung zwingt den Lieferanten mitzuziehen.
• Der Lieferant stellt aus, Sie vertrauen: Code-Signatur seiner Firmware, Zertifikate seiner Dienste, Signaturen seiner Prüfprotokolle. Seine Umstellung bestimmt, was Ihre Systeme prüfen müssen.
• Beide vertrauen Dritten: öffentliche Zertifizierungsstellen, qualifizierte Vertrauensdiensteanbieter nach eIDAS. Deren Zeitplan gilt für beide.

Jede dieser Richtungen braucht eine eigene Absprache. Die EU-Roadmap weist darauf hin, dass etwa qualifizierte Signaturerstellungseinheiten mit Post-Quanten-Verfahren verfügbar sein müssen, damit Vertrauensdiensteanbieter überhaupt umstellen können.

Ein Fall, wie er im Anlagenbau oft vorkommt: Ein Anlagenbauer in Bayern betreibt eine interne PKI. Sie stellt unter anderem Clientzertifikate für 60 externe Servicetechniker aus, darunter 12 eines slowenischen Lieferanten, mit denen sich diese per VPN an Anlagen anmelden. Gleichzeitig verbaut der Anlagenbauer Sensormodule des slowenischen Lieferanten, deren Firmware mit dessen eigener Code-Signatur-CA signiert ist; der Vertrauensanker steckt im Bootloader der Module.

Bei der Bestandsaufnahme zeigt sich:

• Die eigene Stammzertifizierungsstelle (RSA-4096, gültig bis 2035) liegt in einem HSM, für das der Hersteller ML-DSA mit einer neuen Firmware ankündigt, die eine Neuzertifizierung erfordert.
• Die VPN-Clients der Techniker laufen auf Laptops des Lieferanten. Welche Versionen sie haben, weiß der Anlagenbauer nicht.
• Der Vertrauensanker im Bootloader der Sensormodule ist nicht per Update austauschbar. Module, die heute verbaut werden, prüfen ihre Firmware für immer mit RSA.

Der dritte Punkt ist der teuerste, und er liegt nicht beim Anlagenbauer. Er hängt an einer Designentscheidung des Lieferanten, die beim nächsten Modul anders getroffen werden muss.

„Bitte stellen Sie auf quantensichere Zertifikate um“ ist keine Anforderung, die ein Lieferant erfüllen kann. Er weiß nicht, welche Verfahren Ihre Systeme prüfen werden, ab wann, und ob Sie eine parallele Hierarchie betreiben. Präzise wird die Anforderung erst, wenn Sie selbst diese Fragen beantwortet haben:

• Was Sie liefern: den Zeitplan Ihrer eigenen Umstellung, die Verfahren, die Ihre Zertifizierungsstellen künftig verwenden, und die Übergangszeit, in der beide Hierarchien gelten.
• Was Sie verlangen können: eine Aufstellung, welche Ihrer Zertifikate seine Systeme nutzen und prüfen, mit Version der Clients; einen Plan für seine eigenen Code-Signaturen; bei neuen Geräten einen austauschbaren Vertrauensanker.
• Was Sie nicht verlangen sollten: eine pauschale Zusicherung der Quantensicherheit. Sie ist nicht prüfbar, und solange Ihre eigene Hierarchie nicht feststeht, weiß der Lieferant nicht, wogegen er sie abgeben soll.

Wer als Auftraggeber zuerst die eigene Hierarchie plant, bekommt vom Lieferanten verwertbare Antworten statt Absichtserklärungen.

• Prüfende Seite zuerst inventarisieren. Welche Systeme müssen neue Signaturen prüfen können, und ab welcher Version?
• HSM-Fahrplan beim Hersteller erfragen. Firmware, Zertifizierung, Austauschzyklus.
• Parallele Hierarchie planen statt bestehende umzubauen.
• Vertrauensanker in Geräten austauschbar machen oder bei Neuentwicklung Post-Quanten-Signaturen von Anfang an vorsehen.
• Registrierungsverfahren prüfen: Unterstützt Ihre Automatisierung neue Schlüsseltypen?
• Laufzeiten überdenken: Kürzere Laufzeiten erleichtern spätere Wechsel; lange Vertrauensanker erschweren sie.

„Welchen unserer Zertifikate vertrauen Ihre Systeme, welchen Ihrer Zertifikate vertrauen unsere, und lässt sich der Vertrauensanker in Ihren Geräten per Update austauschen?“

Die Frage deckt alle drei Richtungen ab und endet mit dem Punkt, der am längsten nachwirkt: Vertrauensanker in Geräten, die zwanzig Jahre im Feld bleiben.

Die slowenische Ausgabe richtet sich an Systemadministratoren und Architekten beim Lieferanten: »Postkvantna PKI: zakaj zamenjava certifikata ne zadostuje« (auf Slowenisch). Vorherige Ausgabe: Eine Software-Stückliste ist noch kein Kryptoinventar.

Referenzschema einer PKI mit Lieferantenbezug (von oben nach unten: was am längsten lebt, steht oben). In der slowenischen Ausgabe inhaltlich gleich.

Prüfliste Migrationsabhängigkeiten:

1. Liste aller Vertrauensanker mit Algorithmus, Ablauf und Ort der Verteilung.
2. Für jeden Anker: Wie wird er auf prüfenden Systemen ersetzt (Verteilung, Update, Austausch)?
3. HSM: unterstützte Verfahren heute, angekündigte Firmware, Zertifizierungsstand.
4. Registrierungsverfahren: Unterstützung neuer Schlüsseltypen, Version.
5. Prüfende Software: Bibliotheken und Versionen mit Unterstützung von ML-DSA in X.509 (RFC 9881).
6. Geräte mit begrenzten Ressourcen: Speicher, Paketgröße, Kettenlänge.
7. Code- und Firmware-Signatur: Algorithmus, Schlüsselort, Austauschbarkeit des Ankers im Gerät.
8. Dokumentsignaturen mit langer Beweisfunktion: Verfahren, Vertrauensdiensteanbieter.
9. Zertifikate, die Sie für Lieferanten ausstellen: Anzahl, Clients, Verantwortliche.
10. Zertifikate von Lieferanten, denen Sie vertrauen: Aussteller, Ansprechpartner, deren Plan.
11. Sperrinformationen: Größe, Erreichbarkeit, Signaturverfahren.
12. Laufzeiten: wo verkürzen, um spätere Wechsel zu erleichtern.

Alle erschienenen Ausgaben der Reihe: Übersicht „Post-Quanten-Sicherheit in der Lieferkette“

Nächste Ausgabe (4. 5. 2026): „Der verschlüsselte Kanal allein macht Ihre Lieferantenanbindung nicht quantensicher“

Quellen (Stand 6. 4. 2026): NIST FIPS 204 (August 2024); RFC 9881 „Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA“ (Oktober 2025); NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025), Abschnitte 3.2, 4.2 und 6.3.

Wenn Ihre Stammzertifizierungsstelle älter ist als Ihr ältestes Gerät im Feld: Schreiben Sie uns.