Am 3. Juni hat Let's Encrypt seinen Plan für Post-Quantum-Zertifikate im öffentlichen Web veröffentlicht. Zwei Teile davon sind für die Migrationsplanung wichtig. Erstens wird Let's Encrypt Merkle-Tree-Zertifikate (MTCs) für die Post-Quantum-Authentifizierung einsetzen, mit einer Staging-Umgebung Ende 2026 und produktiver Ausstellung 2027. Zweitens benennt derselbe Plan eine Maßnahme als das Nützlichste, was ein Serverbetreiber dieses Jahr tun kann: hybriden Post-Quantum-Schlüsselaustausch zu aktivieren, die Gruppe X25519MLKEM768.
Das ist die Antwort der Zertifizierungsstelle auf einen Schritt, den Chrome zuvor gemacht hat und den wir im März behandelt haben: Chrome benannte MTCs als bevorzugten Weg für Post-Quantum-Zertifikate im öffentlichen Web. Jetzt hat sich eine Zertifizierungsstelle, die einen großen Anteil dieser Zertifikate ausstellt, auf Termine festgelegt. Chrome legt die Regeln dafür fest, welchen Roots Browser vertrauen, Let's Encrypt stellt die Zertifikate aus, und beide zielen jetzt auf dasselbe Design.
Verschlüsselung zuerst, Authentifizierung später
Der Plan teilt die Post-Quantum-Arbeit in zwei Aufgaben und gibt jeder eine andere Frist.
Verschlüsselung schützt die Vertraulichkeit. Die Bedrohung ist Harvest-Now-Decrypt-Later: Jemand zeichnet heute Ihren verschlüsselten Datenverkehr auf und bewahrt ihn auf, bis ein Quantencomputer den Sitzungsschlüssel wiederherstellen kann. Die Uhr beginnt in dem Moment zu laufen, in dem der Datenverkehr aufgezeichnet wird, nicht erst, wenn der Quantencomputer eintrifft. Jede Sitzung, die bis in die späten 2030er-Jahre vertraulich bleiben muss, ist bereits gefährdet.
Authentifizierung schützt die Identität. Die Bedrohung ist eine gefälschte Signatur, und das Fälschen einer solchen erfordert einen Quantencomputer, der während des Live-Handshakes läuft. Das hängt davon ab, dass die Maschine existiert, und fällt deshalb später an.
Das ist dieselbe Trennung, die ein Handshake-Scan erfasst, und wir haben sie rund um die Private-CA-Arbeit von Sectigo dargelegt. ML-KEM deckt den Schlüsselaustausch ab und stoppt Harvest-Now-Decrypt-Later. ML-DSA deckt Signaturen ab und stoppt Fälschungen. Es sind getrennte Standards für getrennte Schichten, und ein Migrationsplan liest sich klarer, wenn jede ihre eigene Zeile bekommt.
Die Empfehlung von Let's Encrypt betrifft die erste Aufgabe. Aktivieren Sie hybriden Schlüsselaustausch jetzt, denn die großen Browser und Betriebssysteme unterstützen ihn bereits. Ein Server, der keinen Post-Quantum-Schlüsselaustausch aushandelt, bleibt für Harvest-Now-Decrypt-Later offen, weshalb [PQ]probe seine Note bei C deckelt und weshalb die Origin-Zahlen, die hinter der Edge nahe null liegen, wie wir zuvor festgehalten haben, mehr aussagen als die Schlagzeilen-Adoptionswerte. Dass eine Zertifizierungsstelle dieser Größe dasselbe sagt, ist ein nützlicher externer Bezugspunkt.
Warum die Authentifizierung schwerer ist
Die Authentifizierung hinkt der Verschlüsselung hinterher, weil Post-Quantum-Signaturen groß sind. ML-DSA-44 ist eines der kleineren standardisierten Verfahren, und seine Signatur belegt etwa 2.420 Bytes gegenüber 256 für RSA-2048 und 64 für ECDSA-P256. Die öffentlichen Schlüssel folgen demselben Muster: 1.312 Bytes für ML-DSA-44 gegenüber 256 und 64. Ein typischer Web-Handshake trägt fünf Signaturen und zwei öffentliche Schlüssel, sodass der durchgängige Wechsel auf ML-DSA einen Handshake über 10 KB treibt. Cloudflare hat gemessen, dass bei dieser Größe ein messbarer Anteil der TLS-Verbindungen in echten Netzen fehlschlägt und der Rest langsamer läuft. Die Byte-Werte haben wir zuvor durchgerechnet.
Merkle-Tree-Zertifikate verringern die Größe, indem sie ändern, wie das Zertifikatsvertrauen aufgebaut ist, nicht den Algorithmus darunter. Statt jedes Zertifikat einzeln zu signieren, signiert eine MTC-Stelle einen ganzen Stapel auf einmal, unter einer Signatur. Clients halten sich mit diesen Stapelsignaturen, Landmarks genannt, außerhalb des TLS-Handshakes aktuell. Im Normalfall legt ein Server eine Signatur, einen öffentlichen Schlüssel und einen kurzen Nachweis vor, dass das Zertifikat im veröffentlichten Baum steht, was zusammen weniger ergibt als die heutige Zertifikatskette, obwohl es Post-Quantum-Algorithmen verwendet. Eine größere eigenständige Form ist der Rückfall, wenn der Landmark eines Clients veraltet ist. Weil jedes Zertifikat von vornherein Teil eines veröffentlichten Merkle-Baums ist, ist Certificate Transparency eingebaut statt nachträglich aufgesetzt, und ein Zertifikat kann außerhalb des Baums nicht existieren.
Let's Encrypt merkt an, dass die Ausstellung von MTCs in diesem Maßstab Änderungen an seinen Ausstellungssystemen erfordert, am ACME-Protokoll, mit dem seine Abonnenten Zertifikate beziehen, an seinen Sperr- und Betriebswerkzeugen und an den Transparency-Logs, die unter MTCs Teil der Ausstellung werden. Es betreibt Certificate-Transparency-Logs, die append-only Merkle-Bäume sind, seit 2019, die Kerndatenstruktur betreibt es also bereits. Parallel verfolgt es den herkömmlichen Weg, ML-DSA in X.509 unter RFC 9881 und in TLS unter draft-ietf-tls-mldsa, da das Ergebnis ein MTC oder ein ML-DSA-signiertes X.509-Zertifikat sein könnte, je nachdem, wie sich die Standards und Root-Programme festlegen. Das MTC-Design wird in der IETF-Arbeitsgruppe PLANTS standardisiert, und Cloudflare und Chrome testen es gegen Live-Datenverkehr.
Wo die Termine liegen
Der Zeitplan von Let's Encrypt fügt sich in eine Reihe von Fristen ein, auf die der Plan selbst verweist. CNSA 2.0 bringt US-Systeme der nationalen Sicherheit auf einem Zeitplan bis 2030 und 2035 zu Post-Quantum-Algorithmen. Der Entwurf der NIST-Leitlinie würde RSA-2048 und P-256 nach 2030 abkündigen und nach 2035 untersagen. Der EU-Fahrplan zielt auf Hochrisikosysteme bis Ende 2030 und auf breite Migration bis 2035. Google hat erklärt, seine Dienste bis 2029 umzustellen, und Cloudflare hat eine ähnliche Zusage gemacht. Go 1.27 nimmt ML-DSA in seine Standardbibliothek auf, was die Kosten der Einbindung senkt.
Keine dieser Vorgaben bindet das öffentliche Web direkt. Zusammen stecken sie das Zeitfenster zum Ende des Jahrzehnts ab, auf das die Bibliotheken, Browser und Zertifizierungsstellen hinter dem Web nun hinarbeiten. Staging Ende 2026 und Produktion 2027 setzen Let's Encrypt vor die regulatorischen Termine und in Gleichschritt mit den Zusagen der Browser und CDNs. Wir verfolgen diese neben den übrigen auf der Compliance-Timeline.
Was Sie messen können
Wenn Sie Ihre eigene Position prüfen, stehen die beiden Aufgaben an unterschiedlichen Punkten.
Den Schlüsselaustausch können Sie heute messen, und er hat Vorrang. Ein Scan eines Live-Handshakes zeigt die tatsächlich ausgehandelte Gruppe, die bei den meisten Origin-Servern noch ein klassischer Austausch über elliptische Kurven ist. Das ist der Wert, den es jetzt zu senken gilt, und es ist der, den Let's Encrypt dem Ökosystem zu beheben aufgibt.
Die Zertifikatsauthentifizierung wird zu einem zweiten Punkt, den man beobachtet, sobald die MTC-Ausstellung in Produktion geht. Die Unterscheidung dort ist dieselbe, die bereits für den Schlüsselaustausch gilt. Ob eine Zertifizierungsstelle Post-Quantum-Zertifikate ausstellen kann, ist getrennt davon, ob ein bestimmter Server in einer Live-Sitzung eines vorlegt und aushandelt. Das ist dieselbe Edge-gegen-Origin-Lücke, die wir gesehen haben, als die Edge-Adoption der nahezu null liegenden Origin-Bereitstellung weit voraus war. Dass ein Anbieter angibt, Post-Quantum-Zertifikate zu unterstützen, beweist nicht, dass ein bestimmter Endpunkt eines aushandelt. Das bestätigen Sie, indem Sie den Handshake betrachten.
Auch das Ziel für die Authentifizierung steht noch nicht fest. Die Wahl zwischen Merkle-Tree-Zertifikaten und ML-DSA-signiertem X.509 und die Root-Programm-Regeln dazu werden noch ausgearbeitet. Eine einzelne Momentaufnahme der Vorbereitung sagt weniger aus, solange sich das Ziel noch bewegt. Die verlässlichere Lesart ist die Richtung der Veränderung über wiederholte Scans, gemessen an einem Bezugspunkt, der sich selbst bewegt.
Langlebige Schlüssel sind die Ausnahme
Eine Einschränkung liegt über dem Gedanken, dass die Authentifizierung warten kann. Sie gilt für das Leaf-Zertifikat, das ein Server während eines Handshakes vorlegt, wo die Fälschung einen Quantencomputer erfordert, der im Moment der Verbindung aktiv ist. Sie gilt deutlich weniger bei langlebigem Signaturmaterial. Root-CA-Schlüssel und Code-Signing-Schlüssel signieren Dinge, die über Jahre vertrauenswürdig bleiben müssen, und der Plan kennzeichnet langlebige Schlüssel als besonders wertvolle Ziele. „Authentifizierung ist weniger dringend“ als pauschale Regel zu lesen, würde genau die Schlüssel mit der längsten Lebensdauer aufschieben. Die richtige Reihenfolge trennt ein kurzlebiges Leaf-Zertifikat von einem Root, der Jahrzehnte halten muss.
Was jetzt zu tun ist
Für die meisten Betreiber läuft der Plan auf eine Sache hinaus, die jetzt zu tun ist, und eine, die zu beobachten ist. Die Sache, die zu tun ist, betrifft die Vertraulichkeit: hybriden Post-Quantum-Schlüsselaustausch aktivieren und die ausgehandelte Gruppe im Handshake prüfen. Das deckt sich mit der eigenen Empfehlung von Let's Encrypt. Die Sache, die zu beobachten ist, betrifft die Authentifizierung: Post-Quantum-Zertifikate sind noch einige Jahre entfernt, werden über ACME kommen, so wie es die heutigen Zertifikate tun, und bringen sowohl ein neues Zertifikatsformat zum Aushandeln als auch eine neue Eigenschaft zum Prüfen mit. Wer ACME-Clients oder Zertifikats-Pipelines betreibt, sollte die Arbeitsgruppe PLANTS jetzt verfolgen, da die Client-Unterstützung vorhanden sein muss, bevor die Ausstellung im großen Maßstab hilft.