ML-DSA-Zertifikate und Post-Quanten-PKI: eine quantensichere CA aufbauen (Leitfaden 2026)

ML-DSA-Zertifikate sind X.509-Zertifikate, deren öffentlicher Schlüssel und Signatur ML-DSA verwenden, den Module-Lattice-Based Digital Signature Algorithm, den NIST im August 2024 in FIPS 204 standardisiert hat. Sie ersetzen RSA- und ECDSA-Signaturen, die ein ausreichend grosser Quantencomputer fälschen könnte, durch ein Signaturverfahren, das Quantenangriffen widerstehen soll. Wie ML-DSA in X.509-Zertifikaten kodiert wird, hat die IETF in RFC 9881 (Oktober 2025) festgelegt.

Für ein Sicherheitsteam lautet die Frage nicht mehr, ob eine PKI auf Post-Quanten-Signaturen umgestellt wird, sondern wo man beginnt und in welcher Reihenfolge. Öffentliches TLS ist noch nicht so weit: Stand Oktober 2026 hat das CA/Browser Forum keinen Ballot verabschiedet, der ML-DSA in öffentlich vertrauenswürdigen TLS-Zertifikaten zulässt. Bei einer privaten PKI sieht es anders aus. Wenn Sie die CA selbst betreiben und sowohl den Aussteller als auch die vertrauenden Parteien kontrollieren, können Sie schon jetzt eine Post-Quanten-Zertifizierungsstelle aufbauen und testen.

Dieser Leitfaden erklärt, was ML-DSA und SLH-DSA sind, wie stark Zertifikatsketten tatsächlich wachsen, wo die IETF-Standards stehen, wann hybride (Composite-)Zertifikate reinen Post-Quanten-Zertifikaten vorzuziehen sind, und beschreibt Schritt für Schritt einen Migrationspfad für eine private CA-Hierarchie.

---

Inhaltsverzeichnis

1. Warum Post-Quanten-PKI jetzt zählt
2. ML-DSA und SLH-DSA: die beiden NIST-Signaturstandards
3. Was sich bei Zertifikaten und Ketten ändert
4. Stand der Standards: IETF LAMPS und das CA/Browser Forum
5. Warum mit der privaten PKI beginnen
6. Hybride Zertifikate vs. reine PQC: Entscheidungstabelle
7. Migrationspfad für eine private CA-Hierarchie
8. Eine Post-Quanten-Zertifizierungsstelle mit DuoKey betreiben
9. FAQ

---

Warum Post-Quanten-PKI jetzt zählt

Verschlüsselung und Signaturen sind unterschiedlichen Quantenrisiken ausgesetzt. Verschlüsselter Datenverkehr lässt sich heute aufzeichnen und später entschlüsseln (store now, decrypt later); deshalb wurde zuerst der Schlüsselaustausch umgestellt. Signaturen werden im Moment der Verwendung geprüft, eine gefälschte Signatur spielt also erst dann eine Rolle, wenn jemand tatsächlich eine fälschen kann. Das klingt nach mehr Zeit, doch die PKI hat die längsten Vorlaufzeiten in der gesamten Kryptografie:

• Root-CAs leben jahrelang. Eine heute erstellte Root ist oft noch ein Jahrzehnt später vertrauenswürdig. Eine Root, die Sie jetzt mit RSA oder ECDSA erstellen, muss ersetzt werden, bevor Quantenfälschungen praktikabel werden.
• Trust Stores ändern sich langsam. Eine neue Root auf jeden Server, jeden Laptop, jedes Container-Image, jede Appliance und jedes eingebettete Gerät zu bringen, dauert länger, als sie auszustellen.
• Es gibt langlebige Signaturen. Firmware, Code-Signaturen und signierte Dokumente müssen unter Umständen über viele Jahre verifizierbar bleiben.

Eine PKI-Migration beginnt daher an der Spitze der Hierarchie und bei der Verteilung des Vertrauens, lange bevor sich das letzte Endzertifikat ändert. Aufsichtsbehörden erwarten einen Plan; für Schweizer Banken siehe die Post-Quanten-Migration nach FINMA 05/2026.

---

ML-DSA und SLH-DSA: die beiden NIST-Signaturstandards

NIST hat beide Standards am 13. August 2024 veröffentlicht:

• FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Standard), abgeleitet von CRYSTALS-Dilithium.
• FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Standard), abgeleitet von SPHINCS+.

ML-DSA-Parametersätze (FIPS 204)

FIPS 204 definiert drei Parametersätze. Grössen in Bytes gemäss FIPS 204, Tabelle 2; Sicherheitskategorien gemäss Abschnitt 4.

FIPS 204 drückt die Stärke nicht als «128 Bit Sicherheit» aus. Jede Kategorie bedeutet, dass das Brechen des Parametersatzes mindestens die Ressourcen erfordert, die zum Brechen einer Referenz-Blockchiffre oder -Hashfunktion nötig sind. In der Praxis ist ML-DSA-65 ein gängiger Standard für CA- und Serverzertifikate, ML-DSA-87 für Roots und Einsätze mit hohen Sicherheitsanforderungen und ML-DSA-44 dort, wo die Grösse am meisten zählt.

SLH-DSA: klein vs. schnell

SLH-DSA stützt sich ausschliesslich auf die Sicherheit von Hashfunktionen, eine konservative Annahme, die von der Gittermathematik hinter ML-DSA unabhängig ist. FIPS 205 genehmigt 12 Parametersätze, jeweils mit SHA-2 oder SHAKE instanziiert. Das Suffix zeigt den Kompromiss an: «s»-Sätze sind auf relativ kleine Signaturen ausgelegt, «f»-Sätze auf relativ schnelle Signaturerzeugung.

Die öffentlichen Schlüssel sind winzig, die Signaturen gross, und das Signieren ist im Vergleich zu ML-DSA langsam. Damit eignet sich SLH-DSA für Roots und andere Schlüssel, die selten signieren und lange halten müssen, und schlecht für TLS-Endzertifikate, die bei jedem Handshake signieren.

ML-DSA vs. SLH-DSA im Überblick

---

Was sich bei Zertifikaten und Ketten ändert

Ein X.509-Zertifikat enthält den öffentlichen Schlüssel des Subjekts und die Signatur des Ausstellers. Mit ECDSA P-256 bewegen sich beide im Bereich von einigen Dutzend Bytes. Mit ML-DSA werden sie in Kilobytes gemessen.

Nach den Grössen aus FIPS 204 enthält ein ML-DSA-65-Zertifikat, das von einem ML-DSA-65-Aussteller signiert wurde, 1952 + 3309 = 5261 Bytes an Schlüssel- und Signaturmaterial, noch vor Namen oder Erweiterungen. In einem TLS-1.3-Handshake sendet der Server in der Regel sein Endzertifikat und das Intermediate-Zertifikat sowie eine CertificateVerify-Signatur. Eine durchgehende ML-DSA-65-Kette fügt damit ungefähr Folgendes hinzu:

Was das in der Praxis bedeutet:

• Grösse des Handshakes. Eine Kette von mehr als 13 KB passt nicht mehr in wenige Pakete. Rechnen Sie in verlustbehafteten Netzen mit zusätzlichen Roundtrips und prüfen Sie Middleboxes, Load Balancer und Proxys mit festen Puffergrenzen.
• Ressourcenbeschränkte Geräte. IoT- und OT-Geräte mit wenig Speicher, langsamen Verbindungen oder festen Speicherplätzen für Zertifikate können ML-DSA-Ketten möglicherweise weder speichern noch parsen. Erfassen Sie sie frühzeitig.
• Speicherung und Logging. Zertifikatsdatenbanken, mit ML-DSA signierte CRLs, OCSP-Antworten und Certificate-Transparency-Logs wachsen allesamt. Die Kapazität der CT-Logs ist eines der Bedenken, die in den Diskussionen des CA/Browser Forum geäussert wurden.
• Kurze Ketten helfen. Jedes entfernte Intermediate spart mit ML-DSA-65 rund 5 KB. Die Post-Quanten-Umstellung ist ein guter Zeitpunkt, um historisch gewachsene Hierarchien zu verflachen.

Planen Sie die Erneuerungsseite mit dem ACME-Automatisierungsleitfaden für private CAs und dem Zeitplan zur 47-Tage-Laufzeit von TLS-Zertifikaten: Kürzere Laufzeiten und grössere Zertifikate drängen beide zu einer vollständig automatisierten Ausstellung.

---

Stand der Standards: IETF LAMPS und das CA/Browser Forum

Der Composite-Entwurf definiert 18 Kombinationen von ML-DSA mit einem klassischen Algorithmus, zum Beispiel id-MLDSA65-ECDSA-P256-SHA512 und id-MLDSA87-ECDSA-P384-SHA512. Eine Composite-Signatur ist nur gültig, wenn jede Teilsignatur verifiziert werden kann; ein Angreifer müsste also beide Algorithmen brechen. Bis der RFC veröffentlicht ist, können sich OIDs und Kodierungen noch ändern. Setzen Sie Composite-Zertifikate deshalb nur in Tests oder privat ein und verfolgen Sie den finalen RFC.

Öffentliches TLS. Die Server Certificate Working Group des CA/Browser Forum arbeitet spätestens seit Frühjahr 2026 an einem Ballot «Allow ML-DSA». Das Protokoll vom Mai 2026 hält offene Fragen zur Kapazität der Certificate-Transparency-Logs fest sowie die Frage, ob klassische X.509-Zertifikate überhaupt Teil des Post-Quanten-Übergangs sein werden; erwähnt wurden auch Merkle Tree Certificates. Laut dem Protokoll vom August 2026 wird die Arbeit an einem kombinierten Ballot fortgesetzt. Auf der Ballot-Liste des Forums erscheint kein ML-DSA-Ballot. Dasselbe Protokoll vom Mai hält fest, dass die Unterstützung von ML-DSA-Vertrauensankern für private PKI in TLS 1.3 mit Chrome 150 ausgeliefert wird.

---

Warum mit der privaten PKI beginnen

Eine private (interne) CA ist der Ort, an dem Post-Quanten-Zertifikate heute einsetzbar sind, und zwar aus drei Gründen:

1. Sie kontrollieren beide Enden. Sie entscheiden, welche Vertrauensanker Ihre Clients installieren und welche Bibliotheken Ihre Server verwenden. Kein Root-Programm muss Ihre Root genehmigen.
2. Die Auswirkungen bleiben begrenzt. Sie können ML-DSA in einem Service Mesh, einem VPN oder einer Geräteflotte pilotieren und zurückrollen, ohne Kunden zu beeinträchtigen.
3. Sie gewinnen die nötigen Belege. Echte Messwerte zu Handshake-Grösse, Latenz und Gerätekompatibilität in Ihrer Umgebung machen aus einer Roadmap ein finanziertes Projekt.

Typische erste Kandidaten: mTLS zwischen Services innerhalb von Kubernetes, interne APIs, VPN und Geräteidentitäten, bei denen Sie den Client ausliefern, sowie Code- oder Firmware-Signierung mit eigenem Verifier. Belassen Sie öffentlich erreichbare Websites auf klassischen Zertifikaten öffentlicher CAs, bis sich die WebPKI-Regeln ändern. Läuft Ihre interne PKI auf Active Directory Certificate Services, prüfen Sie deren bekannte Einschränkungen (siehe Verwandte Ressourcen), bevor Sie darauf eine PQC-Hierarchie planen.

---

Hybride Zertifikate vs. reine PQC: Entscheidungstabelle

Hybride Zertifikate kombinieren einen Post-Quanten- und einen klassischen Algorithmus, sodass das Ergebnis sicher bleibt, solange einer der beiden hält. Der in IETF LAMPS standardisierte Ansatz ist das Composite-Zertifikat: ein Zertifikat mit einem zusammengesetzten öffentlichen Schlüssel und einer zusammengesetzten Signatur (zum Beispiel ML-DSA-65 + ECDSA P-256). Die Alternative sind parallele Ketten: eine klassische und eine reine PQC-Kette nebeneinander, wobei jeder Client diejenige verwendet, die er versteht.

Zwei Punkte werden oft übersehen. Ein Composite-Zertifikat ist für einen rein klassischen Client nicht lesbar: Es verwendet einen neuen Algorithmus-Identifier, ein alter Verifier scheitert also trotzdem. Und Composite-Zertifikate sind etwas grösser als reine ML-DSA-Zertifikate, da sie zusätzlich den klassischen Schlüssel und die klassische Signatur enthalten.

---

Migrationspfad für eine private CA-Hierarchie

Eine praxistaugliche Abfolge, um eine interne PKI auf Post-Quanten-Signaturen umzustellen:

Schritt 1: Bestand erfassen

Erfassen Sie jede CA mit Algorithmus, Schlüssellänge, Gültigkeit und Speicherort des Schlüssels sowie jeden Zertifikatsnutzer, der einen neuen Vertrauensanker benötigt. Eine Cryptographic Bill of Materials (CBOM) und ein Discovery-Scan liefern den Ausgangspunkt; Cryptographic Posture Management hält ihn aktuell.

Schritt 2: Algorithmen pro Ebene wählen

Der Algorithmus der ausstellenden CA muss einer sein, den die übergeordnete CA signieren kann und den die Verifier ihrer untergeordneten Zertifikate verstehen. Hängen Sie kein PQC-Intermediate unter eine klassische Root und nennen die Kette dann quantensicher: Ein Angreifer, der die Signatur der Root fälschen kann, kann die gesamte Kette fälschen.

Schritt 3: Parallel eine neue PQC-Root erstellen

Erzeugen Sie den Schlüssel der neuen Root in einem HSM oder Vault, niemals auf einer Workstation. Lassen Sie die bestehende klassische Root weiterlaufen. Während des Übergangs werden beide Hierarchien nebeneinander betrieben.

Schritt 4: Den neuen Vertrauensanker frühzeitig verteilen

Dies ist der längste Schritt. Bringen Sie die PQC-Root in die Trust Stores der Betriebssysteme, in Container-Basis-Images, Java-Truststores, Profile des Mobile Device Management und in Geräte-Firmware. Die Verteilung des Ankers kostet zur Laufzeit nichts, solange er nicht genutzt wird; beginnen Sie also jetzt, auch wenn die Ausstellung später folgt.

Schritt 5: Zuerst PQC-Intermediates, dann Endzertifikate ausstellen

Erstellen Sie ML-DSA-Intermediates unter der neuen Root. Stellen Sie eine Servicegruppe nach der anderen auf Endzertifikate aus der PQC-Kette um, mit automatisierter Registrierung (ACME, EST, SCEP oder CMP), damit die Erneuerung nicht von Personen abhängt.

Schritt 6: Parallele Ketten betreiben, messen, dann umstellen

Liefern Sie klassische und PQC-Ketten an die Clients aus, die jeweils dafür ausgelegt sind. Messen Sie Handshake-Grösse, Latenz und Fehler. Sobald eine Gruppe vertrauender Parteien vollständig PQC-fähig ist, stellen Sie für sie keine klassischen Zertifikate mehr aus.

Schritt 7: Die klassische Hierarchie stilllegen

Lassen Sie klassische Endzertifikate auslaufen, widerrufen Sie die verbleibenden, veröffentlichen Sie finale CRLs und entfernen Sie anschliessend die klassische Root aus den Trust Stores.

---

Eine Post-Quanten-Zertifizierungsstelle mit DuoKey betreiben

Das Zertifikatsmanagement von DuoKey in DuoKey Cockpit ist auf den oben beschriebenen Migrationspfad ausgelegt. Laut der PKI-Dokumentation von DuoKey:

• Algorithmen. RSA-2048/4096, EC-P256/P384, ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) sowie ein hybrides Composite aus ML-DSA-65 + ECDSA-P256, eine Kombination, die auch in der Liste des IETF-Composite-Entwurfs erscheint.
• CA-Hierarchie. Root-, Intermediate-/ausstellende und externe (importierte) CAs. Cockpit erzwingt die Algorithmuskompatibilität mit der übergeordneten CA, sodass PQC- und hybride Ketten durchgängig verifiziert werden. Der CA-Lebenszyklus umfasst Suspendieren und Reaktivieren, einfachen und kaskadierenden Widerruf sowie Archivierung.
• Vault-signierte PQC-CAs. Die Signaturschlüssel von PQC- und hybriden CAs liegen im Vault oder HSM und werden nicht lokal erzeugt; bei ausgestellten PQC-Zertifikaten liegt auch der Schlüssel des Endzertifikats im Vault. Vault-gestützte CAs können externe, HSM-gestützte Vaults nutzen, zum Beispiel Securosys (HSM nach FIPS 140-2 Level 3).
• Lebenszyklus. Genehmigungsworkflow für CSRs (Anfrage, Genehmigung oder Ablehnung, Ausstellung), Erneuerung, Widerruf mit Gründen nach RFC 5280 sowie CRL und OCSP-Responder pro CA.
• Registrierung. ACME (RFC 8555) mit http-01- und dns-01-Challenges, EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), Kubernetes cert-manager über ACME und ein KMIP-2.1-Server-Endpunkt, dazu Deployment-Konnektoren mit Validierung und Rollback pro Job.

Um Kubernetes cert-manager über ACME auf eine DuoKey-CA zu verweisen, verwenden Sie die Directory-URL der CA:

# ClusterIssuer, der cert-manager über ACME auf eine DuoKey-CA verweist
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory

Die Dokumentation von DuoKey gibt dieselbe Empfehlung wie dieser Leitfaden: PQC dort einsetzen, wo Sie beide Enden kontrollieren, und das hybride Composite dort, wo Sie mit klassischen vertrauenden Parteien interoperieren müssen, denn «not every browser, server or device understands ML-DSA / SLH-DSA yet».

Um herauszufinden, welche Zertifikate und Schlüssel zuerst umgestellt werden müssen, beginnen Sie mit dem kostenlosen Quantum Readiness Score.

---

FAQ

Q: Was ist ein ML-DSA-Zertifikat?

Ein ML-DSA-Zertifikat ist ein X.509-Zertifikat, das für seinen öffentlichen Schlüssel und seine Signatur ML-DSA (FIPS 204) statt RSA oder ECDSA verwendet. Die Kodierung ist in RFC 9881 definiert. Es ist darauf ausgelegt, auch gegenüber Angriffen mit Quantencomputern sicher zu bleiben.

Q: Unterstützen Browser ML-DSA-Zertifikate?

Für das öffentliche Web noch nicht. Das CA/Browser Forum hat keinen Ballot verabschiedet, der ML-DSA in öffentlich vertrauenswürdigen TLS-Zertifikaten zulässt; öffentliche CAs können sie daher nicht für Websites ausstellen. Für private PKI halten die Protokolle des CA/B Forum vom Mai 2026 fest, dass die Unterstützung von ML-DSA-Vertrauensankern für private PKI in TLS 1.3 mit Chrome 150 ausgeliefert wird.

Q: Was ist der Unterschied zwischen ML-DSA und SLH-DSA?

ML-DSA (FIPS 204) basiert auf Gittern, mit Schlüsseln und Signaturen von einigen Kilobytes und schnellem Signieren. SLH-DSA (FIPS 205) stützt sich ausschliesslich auf Hashfunktionen, mit öffentlichen Schlüsseln von 32 bis 64 Bytes, aber Signaturen von etwa 7,9 KB bis 49,9 KB und langsamerem Signieren. ML-DSA eignet sich für die meisten Zertifikate, SLH-DSA für langlebige Roots und die Signierung von Firmware.

Q: Was ist ein Composite-Zertifikat (hybrides Zertifikat)?

Ein Composite-Zertifikat enthält einen kombinierten öffentlichen Schlüssel, zum Beispiel ML-DSA-65 + ECDSA P-256, und eine kombinierte Signatur, die nur gültig ist, wenn beide Teilsignaturen verifiziert werden. Definiert ist es im IETF-LAMPS-Entwurf draft-ietf-lamps-pq-composite-sigs, der sich in der Warteschlange des RFC Editor befindet, aber noch nicht als RFC veröffentlicht ist.

Q: Welchen ML-DSA-Parametersatz sollte ich verwenden?

ML-DSA-65 (Kategorie 3) ist ein sinnvoller Standard für Intermediates und Server. Verwenden Sie ML-DSA-87 (Kategorie 5) für Roots oder hohe Sicherheitsanforderungen und ML-DSA-44 (Kategorie 2), wo die Zertifikatsgrösse die wichtigste Einschränkung ist.

Q: Wie viel grösser sind ML-DSA-Zertifikate?

Ein ML-DSA-65-Zertifikat, das von einer ML-DSA-65-CA signiert wurde, enthält 5261 Bytes an öffentlichem Schlüssel und Signatur, gegenüber einigen Dutzend Bytes bei ECDSA P-256. Eine Kette aus zwei Zertifikaten plus die Handshake-Signatur fügt einem TLS-1.3-Handshake etwa 13,8 KB hinzu.

Q: Ist ML-DSA für X.509 standardisiert?

Ja. RFC 9881 (Oktober 2025) definiert die Algorithmus-Identifier für ML-DSA in X.509, und RFC 9909 (Dezember 2025) tut dasselbe für SLH-DSA. Beide sind Proposed Standards der IETF.

Q: Sollte ich hybride oder reine Post-Quanten-Zertifikate verwenden?

Verwenden Sie reines ML-DSA, wo Sie den Aussteller und alle vertrauenden Parteien kontrollieren. Setzen Sie Composite-Zertifikate ein, wo eine Richtlinie eine klassische Komponente verlangt oder Sie sich gegen Implementierungsfehler in PQC absichern wollen, und parallele klassische und PQC-Ketten, wo einige Clients rein klassisch bleiben.

Q: Kann ich heute schon eine Post-Quanten-Zertifizierungsstelle aufbauen?

Ja, für eine private PKI. Erstellen Sie eine PQC-Root in einem HSM oder Vault, verteilen Sie sie in Ihre Trust Stores und stellen Sie dann ML-DSA-Intermediates und Endzertifikate über automatisierte Registrierung aus. Betreiben Sie parallele Ketten, bis Ihre Clients bereit sind.

---

Fazit: Checkliste für die Post-Quanten-PKI

Eine Post-Quanten-PKI beginnt an der Spitze der Hierarchie und bei der Verteilung des Vertrauens, nicht beim letzten Endzertifikat. In der privaten PKI können Sie sie heute aufbauen und messen, während die Regeln für die öffentliche WebPKI noch geschrieben werden.

• Jede CA mit Algorithmus, Gültigkeit und Speicherort des Schlüssels erfassen
• Vertrauende Parteien auflisten, die einen neuen Vertrauensanker benötigen, einschliesslich ressourcenbeschränkter Geräte
• Algorithmen pro Ebene wählen (zum Beispiel Root mit ML-DSA-87 oder SLH-DSA, Intermediates mit ML-DSA-65)
• Die PQC-Root in einem HSM oder Vault erzeugen, parallel zur klassischen Root
• Jetzt mit der Verteilung des PQC-Vertrauensankers beginnen
• Die Registrierung (ACME, EST, SCEP oder CMP) automatisieren, bevor PQC-Endzertifikate ausgestellt werden
• Mit einer internen Servicegruppe pilotieren und Handshake-Grösse sowie Fehler messen
• Pro Gruppe vertrauender Parteien zwischen reiner PQC, Composite oder parallelen Ketten entscheiden
• Den Composite-RFC und den ML-DSA-Ballot des CA/B Forum verfolgen

---

Referenzen

• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 204 (PDF), Tables 1 and 2
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST FIPS 205 (PDF), Table 2
• RFC 9881: Internet X.509 PKI: Algorithm Identifiers for ML-DSA
• RFC 9909: Internet X.509 PKI: Algorithm Identifiers for SLH-DSA
• IETF draft-ietf-lamps-pq-composite-sigs: Composite ML-DSA for X.509
• CA/Browser Forum Ballot SMC013: Enable PQC Algorithms for S/MIME
• CA/Browser Forum: Server Certificate WG minutes, 21 May 2026
• CA/Browser Forum: Server Certificate WG minutes, 13 August 2026
• CA/Browser Forum: All ballots
• DuoKey Docs: PKI and SSL overview
• DuoKey Docs: Post-quantum certificates
• DuoKey Docs: Enrollment protocols