Es gibt Dinge in der IT, die man eigentlich nicht anfassen möchte: DNS – Kerberos – BGP.

Und natürlich: Root-CAs.

Denn eine Root-CA hat eine sehr einfache Aufgabe: Sie soll irgendwann irgendwo in einem Trust Store liegen und dann dafür sorgen, dass sich ein Administrator nicht morgens um 07:30 Uhr fragt, warum plötzlich irgendein völlig unbeteiligter Server keine HTTPS-Verbindung mehr aufbauen kann. Das hat bei Let’s Encrypt mit der neuen Generation Y irgendwie nur so mittelgut geklappt. Und bevor jetzt jemand bei Let’s Encrypt hektisch den Kaffee abstellt: Nein. Das Problem ist nicht, dass plötzlich jemand vergessen hätte, was eine Zertifikatskette ist. Das Problem ist viel interessanter. Die PKI war schneller als das Ökosystem, das ihr vertrauen soll. Und genau solche Dinge werden lustig, sobald sie produktiv werden.

Willkommen in Generation Y

Let’s Encrypt hat im September 2025 zwei neue Root-CAs erzeugt:

ISRG Root YR für RSA und
ISRG Root YE für ECDSA.

Dazu kamen die neuen Intermediates YR1/YR2/YR3 und YE1/YE2/YE3. Die Idee ist technisch vernünftig: neue Root-Generation, langfristige Migration, Cross-Signing mit den bisherigen Roots X1 beziehungsweise X2. Let’s Encrypt schreibt selbst, dass die neuen Roots langfristig ihre Vorgänger ersetzen sollen und dafür cross-signiert wurden.

Bis hierhin erstmal alles gut – So macht man PKI. Dann kommt allerdings die Realität…

Der kleine Unterschied zwischen „existiert“ und „wird vertraut“

Eine CA kann ein wunderschönes Root-Zertifikat erzeugen. Sie kann dafür eine Ceremony veranstalten. Man kann das Ding sauber dokumentieren. Man kann sogar eine hübsche Webseite darüber bauen.

Das bringt nur leider dem Linux-Server nichts, wenn dort steht:

/usr/share/ca-certificates/mozilla/

und YR nicht drin ist.

Im Juni 2026 wurde genau das in der Let’s-Encrypt-Community diskutiert: Die gängigen Linux-ca-certificates enthielten weiterhin ISRG Root X1 und X2, aber nicht YR/YE, weil die neuen Roots noch nicht über die Root Programs in diese Trust Stores gelangt waren.

Und bevor jetzt jemand wie Karl-Klugscheisser schreibt:

„Aber YR muss doch gar nicht im Trust Store sein!“

Ja. Exakt. Das ist ja der Punkt.

Der vorgesehene Default-Trust-Path sollte weiterhin über die Cross-Sign auf X1 beziehungsweise X2 führen. Deshalb sagt Let’s Encrypt selbst ausdrücklich, dass Zertifikate über die Y-Generation weiterhin auf X1/X2 zurückgeführt werden und YR/YE gerade deshalb zunächst nicht zwingend lokal vertraut sein müssen. Das Design ist also nicht dumm. Das Problem ist:

Die Welt besteht nicht aus einem einzigen perfekten Chain Builder.

Die Welt besteht aus Vendoren

Und jetzt wird es interessant. Der Admin hat einen Server. Der Server bekommt ein Zertifikat. Der ACME-Client bekommt dazu eine Chain. Der ACME-Client schreibt irgendeine fullchain.pem. Der Webserver liefert diese Chain aus. Dann kommt der Client…

Und der Client macht entweder das Richtige, oder er macht das, was irgendein Entwickler 2018 für ausreichend hielt. Oder der Hersteller hat eine eigene TLS-Library. Oder ein Appliance-Hersteller speichert maximal zwei Zertifikate. Oder irgendein Produkt entscheidet, dass es aus der gelieferten Chain schon irgendwie selbst etwas zusammenbasteln muss.

Und plötzlich haben wir:

certificate verify failed

unable to get local issuer certificate

unknown CA

und im Idealfall natürlich:

works in Chrome

Damit ist die Diagnose dann offiziell vollständig.

Und dann kommt der lustige Teil

Der normale Linux-Admin denkt natürlich zunächst:

„Komisch. Let’s Encrypt. Das lief doch immer.“

Dann:

openssl s_client -connect host.example:443 -showcerts

Dann:

curl -v https://host.example/

Dann:

openssl verify ...

Dann ein Blick in /etc/ssl/certs.

Dann ein Blick auf die Chain. Dann ein Blick auf den ACME-Client. Dann ein Blick auf den Webserver. Dann ein Blick auf das Vendor-Produkt. Dann Kaffee. Dann noch einen Kaffee. Und irgendwann kommt man zu dem herrlichen Ergebnis:

Das Zertifikat ist gültig, die Signaturen sind gültig, Let’s Encrypt ist gültig, Der Server ist gültig, und trotzdem funktioniert HTTPS nicht.

Das ist genau die Art von Fehler, für die man in der IT normalerweise Wochen benötigt, um anschließend festzustellen, dass die eigentliche Ursache auf einer Seite mit 14 Zeilen Dokumentation stand.

Jetzt wird es für LE wirklich unangenehm

Denn genau diese Probleme sind 2026 tatsächlich aufgetaucht. In der Let’s-Encrypt-Community wurden Fälle dokumentiert, bei denen YR-basierte Chains auf Linux-Systemen nicht sauber validiert wurden. In einem Fall wurde sogar Root YR manuell in den lokalen Trust Store installiert, worauf die Verbindung plötzlich funktionierte.

Das ist natürlich ein wunderbarer Workaround. Wir haben jetzt also Let’s Encrypt als öffentliches PKI-Ökosystem.

curl ...
update-ca-certificates

mit einem Root-Zertifikat, das eigentlich irgendwann durch die normale Trust-Store-Infrastruktur kommen sollte.

Ganz großes Kino.

Und nein, daraus folgt nicht, dass Let’s Encrypt grundsätzlich kaputt ist. Aber daraus folgt sehr wohl:

Wenn ein PKI-Rollout dazu führt, dass Administratoren anfangen, öffentliche Root-CAs händisch auf Produktionssysteme zu kopieren, sollte irgendwo jemand sehr aufmerksam zuhören, denn “OH NO – WE F***ED UP BIG TIME…”.

Und dann kam auch noch der Gen-Y-Zwischenfall

Als wäre das Ganze nicht schon interessant genug, gab es im Mai 2026 einen weiteren Gen-Y-Vorfall. Die cross-signierten Gen-Y-Sub-CAs erfüllten eine neue CCADB-Anforderung beim serverAuth EKU nicht. Let’s Encrypt deaktivierte daraufhin vorübergehend die Zertifikatsausstellung aus der betroffenen Cross-Signed-Gen-Y-Hierarchie und stellte die betreffenden Cross-Signs neu aus. Das ist übrigens der Moment, an dem ich als Betreiber langsam aufhöre, mich zu fragen:

„Wann bekomme ich die neue Root?“

und anfange zu fragen:

„Muss ich gerade eigentlich wirklich auf diese neue Root-Generation migrieren?“

Denn PKI ist kein Kubernetes-Release. Da steht nicht „Version 2026.4 ist raus, bitte einmal aktualisieren.“
Bei einer Root-CA hängt ein komplettes Ökosystem daran. Wenn man dort Vertrauen verliert, ist das nicht einfach ein fehlender Patch – dann wird es existenziell. Das eigentliche Produkt von LE ist ausschließlich: Vertrauen.

Ich installiere ein Zertifikat auf meinem Server und erwarte, dass Millionen von Clients sagen:

„Ja. Kenne ich.“

Genau dieses Vertrauen ist der Grund, warum Let’s Encrypt so erfolgreich geworden ist. Und genau deshalb ist ein PKI-Rollout eine andere Liga als ein neues Feature im ACME-API. Wenn plötzlich ein Teil der Clients sagt: „Nein. Kenne ich nicht“ dann ist es komplett egal, wie technisch elegant die neue Chain ist.

Der Benutzer sieht: Die Webseite geht nicht.
Der Admin sieht: TLS kaputt.
Das Management sieht: Warum funktioniert unser Dienst bei Kunden nicht mehr?

Und irgendjemand sagt: „Aber auf meinem Laptop geht es.“ Fantastisch. Das hat die Welt dringend gebraucht.

Das noch größere Problem sind die Vendoren

Let’s Encrypt kann nicht selbst in jedem Windows-, Linux-, Java-, Appliance-, Container-, NAS-, Drucker-, Load-Balancer- und Embedded-Truststore herumeditieren. Natürlich nicht: Dafür gibt es Root Programs.

Mozilla, Microsoft, Apple, Linux-Distributionen, Maintainer.

Und genau deshalb muss eine solche Umstellung mit diesen Leuten koordiniert werden. Let’s Encrypt hat die Generation Y bereits 2025 angekündigt und im März 2026 in der Community erklärt, dass die Anträge zur Aufnahme in die großen Root Programs beginnen. Und noch im Mai 2026 wurde öffentlich darauf hingewiesen, dass YR und YE weiterhin nicht in den großen Trust Stores angekommen waren. Auch die offizielle Let’s-Encrypt-Dokumentation weist darauf hin, dass Chains mit YR/YE als Trust Anchor voraussichtlich gerade nicht mit den großen Trust Stores funktionieren.

Das ist der Punkt, bei dem ich als Admin etwas unruhig werde. Nicht weil neue Roots böse wären, sondern weil ich bei einer öffentlichen PKI kein Interesse daran habe, der Beta-Tester einer Vertrauenskette zu sein – WHAT THE ACTUAL F Admins bei LE – waren die Kekse lecker?

Cross-Signing ist kein magischer Schutzschild

Cross-Signing ist hervorragend. Es ist genau das richtige Werkzeug für eine Migration. Aber Cross-Signing hat eine unangenehme Eigenschaft: Es funktioniert nur dann zuverlässig, wenn die beteiligten Systeme die Chain auch so behandeln, wie sie geplant wurde. Und genau da sitzen die ganzen lustigen kleinen Überraschungen. Willkommen in der Enterprise-IT. Wenn Let’s Encrypt eines aus der ganzen Nummer mitnehmen sollte, dann bitte dieses: Eine Root-CA darf technisch fertig sein. Sie darf aber operativ noch lange nicht fertig sein.

Technisch fertig bedeutet:

Das Zertifikat existiert und die Signatur stimmt.

Operativ fertig bedeutet:

Die relevanten Root Programs haben es akzeptiert.
Die Betriebssysteme verteilen es.
Die Anwendungen verstehen die Chain.
Die Vendoren haben ihre Produkte getestet.
Und niemand merkt beim nächsten Renewal plötzlich, dass irgendein uraltes Gerät seit Dienstag kein HTTPS mehr kann.

Das sind zwei völlig verschiedene Zustände. Und genau zwischen diesen beiden Zuständen sitzen die Admins. Und jetzt kommt mein eigentliches Problem damit:
Let’s Encrypt hat sich einen unglaublichen Ruf aufgebaut. Nicht weil die Zertifikate irgendwie magisch besser sind als andere Zertifikate. Sondern weil sie funktionieren. Automatisch – Überall – Billig – Langweilig. Und „langweilig“ ist bei PKI ein verdammt großes Kompliment.

Wenn ich also anfangen muss, bei einem Kunden zu erklären:

„Ja, das Zertifikat ist korrekt.
Ja, die Chain ist korrekt.
Ja, Ihr Browser funktioniert.
Nein, der Drucker nicht.
Nein, das alte Java auch nicht.
Nein, das Appliance-Management ebenfalls nicht.
Nein, wir können nicht sicher sagen, welches Gerät als nächstes ausfällt.“

dann ist das exakt das Gegenteil dessen, was Let’s Encrypt bisher stark gemacht hat. Und das ist gefährlich. Nicht weil Let’s Encrypt dann plötzlich keine Zertifikate mehr ausstellen könnte. Sondern weil Administratoren anfangen, Zertifikatsanbieter zu vermeiden. Ganz banal: „Mit dem anderen Anbieter der 10€/Jahr kostet hatten wir diese Scheiße nicht.“ Und sobald dieser Satz in genügend Teams fällt, wird aus einem technischen Migrationsproblem ein Vertrauensproblem.

Der worst case ist: „Dann nehmen wir halt einen anderen.“ Das wäre für Let’s Encrypt wesentlich gefährlicher als zehn Fehlermeldungen in irgendeinem curl. Denn eine CA kann technisch vollkommen sauber arbeiten und trotzdem Vertrauen verlieren, wenn ihre Änderungen regelmäßig dazu führen, dass irgendwo Services brechen. Und genau hier sollte bei Let’s Encrypt meiner Meinung nach die Alarmglocke klingeln.

NEure Fragestellung lautet: „Wie verhindern wir, dass die Community beim nächsten Root-Rollout überhaupt merkt, dass wir etwas geändert haben?“

Mein Rat an Let’s Encrypt?

Ganz einfach: Macht Generation Y zur langweiligsten PKI-Migration der Geschichte. Nicht zur technisch elegantesten, nicht zur modernsten, nicht zur cleversten. Sondern zur langweiligsten. Sorgt dafür, dass zuerst die Root Programs und Vendor-Truststores nachziehen. Testet nicht nur OpenSSL auf einem aktuellen Linux-System. Testet die Dinge, die bei Kunden tatsächlich herumstehen. Und wenn irgendein Hersteller sagt: „Unsere Software kann diese Chain nicht.“, dann ist die Antwort nicht: „Dann soll der Admin halt YR installieren.“ sondern „Okay. Warum kann eure Software das nicht, und wie verhindern wir, dass dieser Kunde deswegen unseren Namen verflucht?“

Denn genau das ist die eigentliche Verantwortung einer öffentlichen CA. Nicht nur Zertifikate auszustellen. Sondern dafür zu sorgen, dass das Internet danach immer noch funktioniert. Und wenn die nächste Generation dafür ein paar Monate länger vorbereitet werden muss? Dann dauert sie eben ein paar Monate länger. Eine Root-CA ist schließlich kein Sprint. Sie ist das Fundament. Und auf ein Fundament schreibt man normalerweise nicht: „YOLO – wir rollen schon mal aus.“