Merkle Tree Certificates: wie Let's Encrypt das Web quantensicher machen will — ohne den Handshake aufzublähen

Teil 1 — Für alle: worum es geht

Aufbau dieses Beitrags: Teil 1 erklärt in Alltagssprache, worum es geht und was es für Sie bedeutet — ohne Vorwissen. Teil 2 ist der technische Deep-Dive mit Zahlen, Mechanik und Standards.

Das Vorhängeschloss und der Ausweis

Wenn in Ihrem Browser das kleine Schloss erscheint, passieren zwei Dinge gleichzeitig. Erstens wird die Verbindung verschlüsselt — niemand auf dem Weg kann mitlesen. Zweitens weist sich die Website aus: Sie zeigt eine Art notariell beglaubigten Ausweis (das TLS-Zertifikat), und Ihr Browser prüft die Unterschrift darauf. Verschlüsselung schützt den Inhalt, der Ausweis schützt davor, mit einem Betrüger zu reden.

Beide Hälften beruhen auf Mathematik, die ein ausreichend grosser Quantencomputer eines Tages brechen könnte. Bei der Verschlüsselung drängt die Zeit besonders: Ein Angreifer kann verschlüsselten Verkehr heute aufzeichnen und später entschlüsseln, sobald die Technik da ist („harvest now, decrypt later“). Beim Ausweis ist die Lage etwas entspannter — eine Unterschrift muss in Echtzeit gefälscht werden, also erst, wenn es einen praktisch nutzbaren Quantencomputer wirklich gibt. Entspannter heisst aber nicht „später anfangen“: Neue Technik braucht Jahre, bis sie überall ankommt, und genau deshalb startet die Branche jetzt.

Warum der naheliegende Fix das Web langsamer macht

Es gibt bereits quantensichere Unterschriften. Das Problem ist nicht, dass sie fehlen — das Problem ist ihre Grösse. Eine der kleineren standardisierten Post-Quantum-Signaturen ist rund 38-mal grösser als das, was heute üblich ist. Ein normaler Verbindungsaufbau (der „Handshake“) trägt nicht eine, sondern mehrere Unterschriften und Schlüssel mit sich. Ersetzt man die alle durch die grossen, neuen, wächst ein einzelner Handshake auf über 10 Kilobyte an.

Das klingt nach wenig. Im Massstab des gesamten Webs ist es das nicht: Forschung von Cloudflare zeigt, dass bei dieser Grösse ein spürbarer Teil der Verbindungen auf echten Netzen ganz scheitert — und der Rest wird langsamer. Jede einzelne TLS-Verbindung weltweit zu verlangsamen, um sich gegen eine Bedrohung zu wappnen, die es noch gar nicht gibt, ist ein schlechtes Geschäft. Und Voreinstellungen sind das, was Sicherheit im Web tatsächlich bewegt.

Die Idee von Let's Encrypt: einmal stempeln statt millionenfach

Hier setzen Merkle Tree Certificates (MTCs) an, die Let's Encrypt am 3. Juni 2026 als seinen geplanten Weg vorgestellt hat. Das Bild dazu: Statt jeden Ausweis einzeln mit einer eigenen, schweren Unterschrift zu versehen, stellt die Zertifizierungsstelle Ausweise in Stapeln aus und setzt eine einzige quantensichere Unterschrift über den ganzen Stapel. Ihr Browser hält diese Stapel-Unterschriften (sie heissen Landmarks) im Hintergrund aktuell — unabhängig vom eigentlichen Seitenaufruf.

Wenn Sie dann eine Website besuchen, muss diese nur noch einen winzigen Beleg mitliefern, dass ihr Ausweis Teil des bekannten Stapels ist. Das Ergebnis ist paradox und schön zugleich: Obwohl quantensichere Verfahren zum Einsatz kommen, ist der Verbindungsaufbau am Ende kleiner als heute. Als angenehmer Nebeneffekt wird die öffentliche Nachvollziehbarkeit von Zertifikaten (die „Certificate Transparency“) zur eingebauten Eigenschaft, statt nachträglich angeflanscht zu werden.

Was das konkret für Sie bedeutet

Für den Moment: nichts. Ihre Let's-Encrypt-Zertifikate werden weiter genau so automatisch ausgestellt und erneuert wie bisher. Die Umstellung passiert über Jahre, nicht über Nacht — Let's Encrypt peilt eine Test-Umgebung Ende 2026 und eine produktionsreife Umgebung 2027 an, und davor müssen Standards, Browser, Bibliotheken und ACME-Clients nachziehen.

Das eine, was Sie heute schon tun sollten, hat mit MTCs gar nichts zu tun, sondern mit der dringenderen Hälfte (der Verschlüsselung): Sorgen Sie dafür, dass Ihre Server hybride post-quantum-Schlüsselvereinbarung unterstützen (das Kürzel lautet X25519MLKEM768). Das schützt heutigen Verkehr vor dem „heute aufzeichnen, später entschlüsseln“-Angriff und ist eine der wirkungsvollsten Massnahmen, die Sie dieses Jahr mit geringem Aufwand umsetzen können. Grosse Browser und Betriebssysteme können es bereits; es fehlt oft nur die Server-Seite.

Teil 2 — Warum Authentifizierung das härtere Grössenproblem ist

Die Post-Quantum-Diskussion drehte sich jahrelang vor allem um Verschlüsselung, und das aus gutem Grund: „Harvest now, decrypt later“ macht aufgezeichneten Verkehr sofort zu einem Risiko, während ein Signatur-Forgery einen real existierenden, kryptografisch relevanten Quantencomputer (CRQC) in Echtzeit voraussetzt. Diese Asymmetrie hat sich verschoben. Die NSA-Suite CNSA 2.0 steuert nationale Sicherheitssysteme seit 2022 auf einen 2030-bis-2035-Zeitplan; NISTs Entwurf IR 8547 würde RSA-2048 und P-256 nach 2030 abkündigen und nach 2035 verbieten; die EU-Roadmap zielt auf Hochrisikosysteme bis Ende 2030. Hinzu kamen 2026 konkrete Anbieter-Fristen: Google will seine Dienste bis 2029 migrieren, Cloudflare zog parallel nach, und Go 1.27 nahm ML-DSA in die Standardbibliothek auf. Diese Mandate binden die öffentliche Web-PKI nicht direkt, setzen aber den Takt für Bibliotheken, Browser und CAs.

Die Web-PKI ist dabei einer der unangenehmsten Orte für Post-Quantum-Signaturen — wegen der Grösse. Die nackten Zahlen aus dem Let's-Encrypt-Beitrag:

Ein typischer Web-PKI-Handshake trägt fünf Signaturen und zwei Public Keys. Ersetzt man diese durch ML-DSA-Äquivalente, schiebt das einen einzelnen TLS-Handshake deutlich über 10 KB. Cloudflares Messungen zeigen die Folge: Auf realen Netzen scheitert dann ein nennenswerter Anteil der Verbindungen ganz, der Rest wird langsamer. Das ist kein Tuning-Problem, sondern ein Default-Problem — und Defaults bewegen Sicherheit im Web.

Wie Merkle Tree Certificates die Mechanik umdrehen

Der Kerngedanke: Nicht jedes Zertifikat trägt seine eigene grosse Post-Quantum-Signatur. Stattdessen stellt die CA Zertifikate im Batch aus und signiert eine kryptografische Festlegung — den Kopf eines Merkle-Baums (den „tree head“) — die potenziell Millionen Zertifikate auf einmal abdeckt. Weil die Grösse eines Merkle-Beweises nur logarithmisch mit der Zahl der Blätter wächst, braucht selbst ein Baum mit Milliarden Zertifikaten nur wenige hundert Byte Beweisdaten.

Die Rollenverteilung dabei:

• Die CA signiert pro Batch genau eine Post-Quantum-Signatur über den Merkle-Tree-Head.
• Der Browser (Relying Party) hält diese Batch-Signaturen — die Landmarks — aktuell, und zwar out-of-band, also getrennt vom TLS-Handshake.
• Der Server liefert im Handshake im Normalfall nur noch eine Signatur, einen Public Key und einen Inclusion-Proof — den Pfad im Merkle-Baum, der zeigt, dass sein Zertifikat unter dem bekannten, signierten Tree-Head hängt. Dieser Pfad ist der „wenige hundert Byte“-Anteil und macht den Handshake kleiner als heute.

Für den Fall, dass der Landmark eines Clients veraltet ist, gibt es die „standalone“-Form: ein etwas grösserer Handshake als Fallback, der ohne aktuellen Landmark auskommt. Das ist die bewusste Degradation für den Rand-, nicht den Normalfall.

Certificate Transparency wird zur Eigenschaft der Ausstellung

Heute ist Certificate Transparency nachträglich angeflanscht: CAs stellen Zertifikate aus, loggen sie separat, und zusätzliche Signaturen (SCTs) reisen im Handshake mit, um das Logging zu bezeugen. Bei MTCs kann ein Zertifikat nicht ausserhalb des Merkle-Baums existieren — Transparenz ist intrinsisch zur Ausstellung. Für Let's Encrypt ist das kein Neuland: Die Organisation betreibt seit 2019 CT-Logs, und das sind append-only Merkle-Bäume — dieselbe Datenstruktur, auf der MTCs aufsetzen, in Produktion und im Web-Massstab erprobt.

Die beweglichen Teile: Standards, Experimente, Fristen

• IETF PLANTS-Arbeitsgruppe — entstanden nach einer erfolgreichen BoF auf der IETF 124 in Montreal, standardisiert das Design. Aktueller Stand u. a. draft-ietf-plants-merkle-tree-certs-04 (Mai 2026). Autorenkreis des zugrundeliegenden Entwurfs: David Benjamin und Devon O'Brien (Google), Bas Westerbaan und Luke Valenta (Cloudflare) sowie Filippo Valsorda.
• Chrome hat MTCs im Februar 2026 als seinen bevorzugten Weg für Post-Quantum-Zertifikate im öffentlichen Web ausgerufen.
• Cloudflare und Chrome fahren bereits ein Feasibility-Experiment mit MTCs gegen echten Internet-Verkehr.
• Paralleler Standard-Strang (von Let's Encrypt ausdrücklich mitverfolgt): ML-DSA-Signaturen in X.509 sind als RFC 9881 standardisiert, ML-DSA in TLS läuft als draft-ietf-tls-mldsa.
• Let's-Encrypt-Fahrplan: Staging-Umgebung, die MTCs ausstellt, Ende 2026; produktionsreife Umgebung 2027. Das verlangt Änderungen quer durch den Stack — Issuance-Infrastruktur, das ACME-Protokoll (RFC 8555) der Subscriber, Revocation- und Betriebs-Tooling sowie die Transparency-Log-Infrastruktur, die MTCs in sich aufnehmen.

Hinweis zur Quellendisziplin: Einzelne Sekundärberichte ordnen RFC 9881 fälschlich „dem ACME-Protokoll“ zu — RFC 9881 ist ML-DSA-in-X.509; ACME selbst ist RFC 8555.

Eine Grössenordnung zur Tragweite: Let's Encrypt stellte im ersten Quartal 2026 rund 54 % aller öffentlichen TLS-Zertifikate aus. Wenn dieser Akteur sich auf MTCs festlegt, wird der Ansatz für die Mehrheit des verschlüsselten Webs tragfähig — das ist der eigentliche Hebel hinter der Meldung.

Was Betreiber und ACME-Client-Maintainer jetzt tun sollten

Heute

Aktivieren Sie hybride Post-Quantum-Schlüsselvereinbarung (X25519MLKEM768) auf Ihren Servern. Das ist die wirksamste Sofortmassnahme gegen „harvest now, decrypt later“ und unabhängig von MTCs. Browser- und OS-Seite sind weitgehend bereit; der Flaschenhals ist die Server-Konfiguration (TLS-Terminierung an Reverse-Proxy / Load-Balancer / CDN).

Beobachten

Wer einen ACME-Client pflegt oder eine ACME-getriebene Zertifikats-Pipeline betreibt, sollte jetzt die PLANTS-Arbeitsgruppe und die mtcs@chromium.org-Liste verfolgen. MTCs bringen client-seitige Änderungen mit; ein ACME-Client, der bereit ist, sobald die Ausstellungsseite steht, ist die günstigere Variante.

Inventarisieren

Wo hängt Ihr Betrieb an ACME-Automatisierung (cert-manager in Kubernetes, Caddy/Traefik-Auto-TLS, acme.sh-Cronjobs, Plattform-Integrationen)? Diese Liste ist die Landkarte dafür, wo später client-seitige Anpassungen nötig werden. Heute ändert sich nichts an der Ausstellung — aber die Karte zu haben, bevor man sie braucht, ist der Unterschied zwischen geplantem Nachzug und Hektik.

Was das für unsere Sicht auf Plattformen heißt

Wir behandeln Krypto-Agilität als Plattform-Eigenschaft, nicht als Einmal-Projekt — dieselbe Linie, die wir im Beitrag zu Post-Quantum Security (RFC 9964, ML-DSA) gezogen haben. MTCs sind dafür ein gutes Beispiel: Die Umstellung gelingt nur, wenn Ausstellung, Transport (TLS), Transparenz und Client-Tooling gemeinsam nachziehen, und der einzige Weg, das ohne Web-Bremse zu schaffen, führt über eine Änderung der Mechanik, nicht nur der Algorithmen. Für betreute Stacks heisst das konkret: hybride Schlüsselvereinbarung bereits heute scharf, ACME-Pfade dokumentiert, und die PLANTS-/X.509-ML-DSA-Standards im Blick, damit der Wechsel — ob am Ende MTCs oder ML-DSA-signierte X.509-Zertifikate ausgeliefert werden — ein Konfigurations- und kein Notfall-Thema wird.

Quellen

• Let's Encrypt — A Post-Quantum Future for Let's Encrypt (Andrew Gabbitas, 03.06.2026; Primärquelle)
• Cyber Security News — Let's Encrypt Unveils Merkle Tree Certificates (05.06.2026)
• Google Security Blog — Chrome-Ankündigung zu MTCs (Februar 2026)
• Cloudflare — Another look at PQ signatures (Grössen-/Ausfall-Messungen)
• IETF PLANTS Working Group (Standardisierung MTC)
• RFC 9881 — ML-DSA in X.509