Wenn ein gültiges Let’s-Encrypt-Zertifikat plötzlich nicht mehr gültig ist
In den vergangenen Wochen traten bei mehreren Websites ein ungewöhnliches Problem auf: Firefox verweigerte den Zugriff mit der Meldung, das verwendete Zertifikat sei widerrufen worden. Andere Browser öffneten dieselben Seiten hingegen teilweise ohne Warnung. Auch eine Prüfung mit curl zeigte zunächst ein scheinbar gültiges Zertifikat. Daher kommen Kunden nicht sofort dahinter, dass ihr Zertifikat widerrufen wurde. Die Zertifikatsinhaber wurden von Letsencrypt auch nicht informiert.
Wenn ein derartiges Problem auftritt ist die Lösung einfach. Im ISPConfig bei Letsencrypt den Haken entfernen. Dann warten bis die Rote 1 oben verschwindet, dann wieder anhaken. Man bekommt ein neues gültiges Zertifikat ausgestellt.
Die Ursache lag nicht beim eigentlichen Zertifikat der Website. Widerrufen worden war ein Zertifikat innerhalb der Let’s-Encrypt-Zertifikatskette. (Intermediate Zertificate)
Wie funktioniert eine Zertifikatskette?
Das TLS-Zertifikat einer Website steht nicht für sich allein. Der Browser prüft eine Vertrauenskette, die vereinfacht so aussieht:
Website-Zertifikat
└── Intermediate-Zertifikat
└── Root-Zertifikat
Das Root-Zertifikat ist im Browser oder Betriebssystem bereits als vertrauenswürdig hinterlegt. Da die Root-Zertifizierungsstelle aus Sicherheitsgründen nicht direkt jedes Website-Zertifikat signiert, werden dazwischen sogenannte Intermediate-Zertifizierungsstellen eingesetzt.
Bei der Einführung einer neuen Root-Zertifizierungsstelle gibt es ein zusätzliches Problem: Ältere Geräte und Betriebssysteme kennen die neue Root-Zertifizierungsstelle noch nicht. Deshalb wird ein Übergangszertifikat verwendet, das die neue Hierarchie mit einer bereits bekannten Root-Zertifizierungsstelle verbindet. Man spricht dabei von einem „Cross-Sign“.
Was ist bei Let’s Encrypt passiert?
Let’s Encrypt führte 2025 und 2026 eine neue Zertifikatshierarchie ein. Zu dieser „Generation Y“ gehören die neuen Root-Zertifizierungsstellen:
- ISRG Root YE für ECDSA-Zertifikate
- ISRG Root YR für RSA-Zertifikate
Darunter arbeiten neue Intermediate-Zertifizierungsstellen wie YE1, YE2, YR1 und YR2.
Damit auch Geräte, die den neuen Roots noch nicht direkt vertrauen, Zertifikate aus dieser Hierarchie akzeptieren können, wurden Cross-Sign-Zertifikate ausgestellt. Dadurch konnte beispielsweise die neue Root YR über die bereits verbreitete ISRG Root X1 als vertrauenswürdig bestätigt werden.
Dabei unterlief Let’s Encrypt ein Fehler.
In den betreffenden Cross-Sign-Zertifikaten fehlte die Erweiterung:
Extended Key Usage: TLS Web Server Authentication
Kurz wird diese Erweiterung als serverAuth EKU bezeichnet. Sie legt ausdrücklich fest, dass ein Zertifikat innerhalb einer Zertifikatskette zur Authentifizierung von TLS-Webservern verwendet werden darf.
Nach den seit dem 15. Juni 2025 geltenden Richtlinien des Common CA Database-Programms muss diese Erweiterung in neu ausgestellten cross-signierten Intermediate-Zertifikaten vorhanden sein. Die von Let’s Encrypt im September 2025 ausgestellten Zertifikate entsprachen dieser Anforderung nicht.
Warum mussten die Zertifikate widerrufen werden?
Das Fehlen der Erweiterung bedeutete nicht automatisch, dass die Verschlüsselung gebrochen oder ein privater Schlüssel gestohlen worden war. Es gab nach den veröffentlichten Informationen auch keinen Hinweis auf einen erfolgreichen Angriff auf Let’s Encrypt.
Die Zertifikate waren aber nicht richtlinienkonform ausgestellt worden.
Zertifizierungsstellen müssen die Vorgaben der Browserhersteller und des CA/Browser-Ökosystems strikt einhalten. Andernfalls riskieren sie, dass ihre gesamte Zertifikatshierarchie von Browsern nicht mehr als vertrauenswürdig anerkannt wird.
Let’s Encrypt meldete den Vorfall am 8. Mai 2026, stoppte vorübergehend die Ausstellung über die betroffene Hierarchie und wechselte zunächst auf die bisherige Generation-X-Infrastruktur zurück. Anschließend wurden die fehlerhaften Cross-Sign-Zertifikate widerrufen und am 13. Mai durch korrigierte Zertifikate ersetzt.
Die eigentlichen Website-Zertifikate wurden nicht widerrufen. Sie waren korrekt ausgestellt worden. Ungültig wurde lediglich ein Zertifikat, das für den Aufbau des Vertrauenspfades verwendet wurde.
Die offizielle Beschreibung des Vorfalls findet sich im Incident-Bericht von Let’s Encrypt.
Warum treten die Probleme erst Monate später auf?
Auf einem Webserver oder in einem ACME-Client kann noch das alte, inzwischen widerrufene Cross-Sign-Zertifikat gespeichert sein. Wird später ein Website-Zertifikat erneuert, kann daraus eine Kette gebaut werden, die weiterhin das alte Zertifikat enthält:
Website-Zertifikat
└── YR1 oder YR2
└── altes, widerrufenes Root-YR-Cross-Sign
└── ISRG Root X1
Korrekt wäre dagegen:
Website-Zertifikat
└── YR1 oder YR2
└── neues Root-YR-Cross-Sign
└── ISRG Root X1
Das alte und das neue Cross-Sign sehen auf den ersten Blick fast identisch aus. Sie verwenden denselben Namen und können auch denselben CA-Schlüssel enthalten. Sie unterscheiden sich jedoch unter anderem in der Seriennummer, im Ausstellungsdatum und in den eingetragenen Verwendungszwecken.
Ein ACME-Client, eine Hosting-Verwaltung oder eine lokal gespeicherte Zertifikatskette kann daher weiterhin das falsche Exemplar auswählen. Möglich ist auch, dass das neue Cross-Sign in der vom Webserver ausgelieferten Kette vollständig fehlt.
Dass die Störung nicht bei allen Websites gleichzeitig auftritt, ist deshalb plausibel: Sie wird häufig erst bei der nächsten automatischen Zertifikatserneuerung sichtbar.
Warum funktioniert die Website in manchen Browsern?
Browser prüfen Zertifikatsketten nicht alle auf dieselbe Weise.
Ein Browser kann die vom Webserver gelieferte Kette verwenden. Er kann aber auch bereits gespeicherte Intermediate-Zertifikate heranziehen oder selbst einen alternativen Vertrauenspfad aufbauen.
Dadurch kann dieselbe Website unterschiedlich beurteilt werden:
- Firefox erkennt das widerrufene Zertifikat und blockiert die Verbindung.
- Ein anderer Browser findet selbstständig einen gültigen alternativen Vertrauenspfad.
- Ein aktuelles System vertraut
ISRG Root YRbereits direkt und benötigt das Cross-Sign nicht. - Ein älteres System kennt die neue Root-Zertifizierungsstelle noch nicht und ist auf das korrekte Cross-Sign angewiesen.
- Kommandozeilenprogramme prüfen Widerrufe möglicherweise weniger konsequent oder verwenden einen anderen Zertifikatsspeicher.
Ein erfolgreicher Test mit curl oder einem einzelnen Browser beweist daher nicht, dass die ausgelieferte Zertifikatskette korrekt ist.
Was müssen Websitebetreiber tun?
Betreiber sollten nicht nur das eigentliche Website-Zertifikat, sondern die gesamte vom Server ausgelieferte Zertifikatskette kontrollieren.
Dabei ist zu prüfen:
- Welche Intermediate- und Cross-Sign-Zertifikate liefert der Webserver tatsächlich aus?
- Ist darin noch eine vor dem 13. Mai 2026 ausgestellte und inzwischen widerrufene Version enthalten?
- Hat der ACME-Client bei der letzten Erneuerung eine aktuelle vollständige Kette gespeichert?
- Verwenden Webserver, Loadbalancer und weitere Cluster-Knoten dieselbe aktuelle Zertifikatskette?
- Wurde der Webserver nach der Erneuerung erfolgreich neu geladen?
Meist muss nicht das Website-Zertifikat selbst ersetzt werden. Entscheidend ist, die alte Zertifikatskette durch die aktuelle vollständige Kette von Let’s Encrypt zu ersetzen und anschließend alle beteiligten Dienste neu zu laden.
Fazit
Bei dem Vorfall handelte es sich um einen echten Fehler bei Let’s Encrypt. Cross-signierte Zertifikate der neuen Generation-Y-Hierarchie wurden ohne ein inzwischen vorgeschriebenes serverAuth-Merkmal ausgestellt. Let’s Encrypt musste diese Zertifikate deshalb widerrufen und korrekt neu ausstellen.
Es gab dabei keinen bekannten Bruch der Verschlüsselung und keinen veröffentlichten Hinweis auf kompromittierte Schlüssel. Das Problem war die Nichteinhaltung formaler, aber wichtiger Sicherheits- und Vertrauensrichtlinien.
Dass einige Websites weiterhin betroffen sind, liegt daran, dass Webserver oder ACME-Clients noch das alte widerrufene Cross-Sign ausliefern oder keine vollständige aktuelle Zertifikatskette bereitstellen. Der ursprüngliche Fehler entstand bei Let’s Encrypt – seine verzögerten Auswirkungen zeigen sich nun in der automatisierten Zertifikatsverwaltung einzelner Server.
Durch die Neuaustellung der Zertifikate nach einer bestimmten Zeit verschwinden diese ungültigen Zertifikate mit der Zeit auch von selbst.