Am 7. Oktober 2026 hat Let’s Encrypt den Umstieg auf 64-Tage-Zertifikate angekündigt – Produktionstermin ist der 10. Februar 2027. Das betrifft jede Website mit automatischem ACME-Renewal, also fast alle. Wer den Termin verpasst, bekommt keine Fehlermeldung, sondern einen abgelaufenen Zertifikats-Fehler im Browser. Hier ist, was ich zuerst prüfe.
Die kurzen Antworten vorweg
Drei Fragen bestimmen diese Woche fast jedes Gespräch über TLS. Hier jeweils eine Antwort, die auch ohne den Rest des Artikels trägt.
- Zerbricht mein Let’s-Encrypt-Renewal im Februar 2027? Nein, wenn Ihr ACME-Client ARI auswertet – ja, wenn ein Skript nach 80 oder 83 Tagen erneuert, denn dann läuft es ins Leere; ein 60-Tage-Rhythmus bleibt formal innerhalb der Frist, hat aber nur vier Tage Puffer.
- Brauche ich CAA-Records für meine Domain? Pflicht sind sie nicht – aber ein restriktiver CAA-Record ist die einzige deklarative Sperre gegen Ausstellungen durch fremde Stellen, und ab dem 15. März 2027 müssen Zertifizierungsstellen die Account-Bindung nach RFC 8657 verarbeiten.
- Kann ein gültiges Zertifikat trotzdem gefälscht sein? Ja – im September 2026 erhielten Angreifer über kompromittierte ccTLD-Registries formell korrekt ausgestellte Zertifikate für Google- und YouTube-Domains; die Zertifizierungsstellen haben nach Googles Aussage nichts falsch gemacht.
Was Let’s Encrypt am 7. Oktober angekündigt hat
Let’s Encrypt stellt am 10. Februar 2027 die Standard-Lebensdauer von 90 auf 64 Tage um. Das letzte 90-Tage-Zertifikat läuft nach heutiger Erwartung am 11. Mai 2027 ab; bestehende, gültige Zertifikate werden nicht vorzeitig gesperrt. Zwischen dem 10. Februar und dem 11. Mai läuft also alles Alte aus und alles Neue mit 64 Tagen – wer bis dahin sauber erneuert, hat drei Monate Übergangsfrist, in denen er die Umstellung begleiten kann.
Zweiter Punkt der Ankündigung: Die Wiederverwendung von Validierungen sinkt von 30 auf 10 Tage – und 2028 auf sieben Stunden. Konkret heißt das: Der Nachweis, dass Sie eine Domain kontrollieren, ist bei der nächsten Ausstellung seltener noch gültig; die DNS-basierte Validierung muss öfter tatsächlich klappen. Wer kürzere Lebensdauern will, kann künftig auch 45 oder 6 Tage wählen. Die Rate-Limits bleiben von der Umstellung unberührt.
Der Fahrplan dahinter: CA/Browser Forum
Die 64 Tage sind keine Einzelentscheidung von Let’s Encrypt. Die Baseline Requirements des CA/Browser Forums senken die Höchstgültigkeit von Zertifikaten seit dem 15. März 2026 auf 200 Tage, ab dem 15. März 2027 auf 100 Tage und ab dem 15. März 2029 auf 47 Tage; die maximale Wiederverwendung von Validierungsdaten fällt bis dahin ebenfalls auf 10 Tage. Let’s Encrypt liegt mit 64 Tagen freiwillig unter der ab 2027 geltenden Obergrenze. Ab dem 15. März 2027 gilt außerdem: Zertifizierungsstellen müssen die CAA-Parameter accounturi und validationmethods nach RFC 8657 verarbeiten.
Die Fehler, die niemanden wecken
Das eigentliche Risiko des Umstiegs ist nicht, dass etwas laut kaputtgeht – es ist, dass es leise passiert. Ein Cronjob, der ein fehlgeschlagenes Renewal nicht meldet, läuft einfach weiter; sichtbar wird der Fehler erst beim Besucher, dessen Browser die Seite wegen des abgelaufenen Zertifikats sperrt. Ein Statuscode 200 beweist an dieser Stelle gar nichts – er zeigt nur, dass der Server geantwortet hat, nicht dass das Zertifikat lang genug läuft.
Let’s Encrypt benennt die typische Bruchstelle selbst: feste Erneuerungs-Abstände in Cronjobs, Wrapper-Skripten und Runbooks. Ein Rhythmus von 83 oder 80 Tagen erneuert künftig, nachdem das Zertifikat schon abgelaufen ist; 60 Tage bleiben formal innerhalb der Frist, lassen aber nur vier Tage Puffer. Die Empfehlung lautet, auf rund zwei Drittel der Lebensdauer umzustellen – bei 64 Tagen also um Tag 42. Die Suche nach den festen Werten ist ein Einzeiler:
grep -rnE "\b(83|80|60)\b" /etc/cron.d /etc/cron.daily /usr/local/bin 2>/dev/nullDer saubere Ausweg heißt ARI – ACME Renewal Information. ARI erlaubt Let’s Encrypt, Ihrem Client mitzuteilen, wann er erneuern soll. Wer einen Client nutzt, der ARI auswertet, braucht keine Änderung; wer Skripte mit festen Werten fährt, bringt sie auf den zwei-Drittel-Rhythmus.
Und so sieht der read-only-Check aus, der Ihnen das Ablaufdatum ohne Browser zeigt:
openssl s_client -connect beispiel.de:443 -servername beispiel.de </dev/null 2>/dev/null | openssl x509 -noout -enddate -issuerAb dem 14. Oktober 2026 stellt die Staging-Umgebung von Let’s Encrypt auf 64-Tage-Zertifikate um. Damit haben Sie rund vier Monate, jeden Automatismus gegen eine Umgebung zu proben, die sich ab Februar genauso verhält – ein Fehler dort kostet nichts. Richten Sie eine Test-Domain einmal gegen Staging und lassen Sie das komplette Renewal durchlaufen, bevor Sie am Produktions-Rhythmus drehen.
Warum ein gültiges Zertifikat nichts mehr beweist
Ende September 2026 sind die Registries von Ghana (.gh, 22. September), Sierra Leone (.sl, 25. September) und Amerikanisch-Samoa (.as, 27. September) kompromittiert worden. Die Angreifer veränderten autoritative DNS-Einträge und ließen dafür Zertifikate für Google- und YouTube-Domains ausstellen – formell korrekt, weil sie die Domain-Kontrolle auf Registry-Ebene tatsächlich in der Hand hatten. Googles eigene Einordnung:
„we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong“
iTnews zählte 32 Ausstellungen zwischen dem 22. und 27. September; auf Google und YouTube entfallen davon 12 Zertifikate – 11 von Let’s Encrypt, eins von ZeroSSL. Chrome hat die betroffenen Zertifikate umgehend über CRLSets blockiert; die Sperrwellen der Zertifizierungsstellen liefen am 26. September und 1. Oktober. CT-Log-Daten zeigten weitere Betroffene, darunter mehrere global bekannte Marken und verbreitete Online-Dienste.
Zwei Erkenntnisse für Domain-Inhaber: Erstens schützt CRLSets nur Chrome-Nutzer – für Firefox und Safari zählt die Sperrung durch die Zertifizierungsstelle selbst. Zweitens bemerken Sie eine Ausstellung für Ihre Domain nur, wenn Sie hinschauen. Google empfiehlt deshalb ausdrücklich zwei Dinge: CT-Logs zu überwachen, was eine Benachrichtigung nahezu in Echtzeit bei jeder Ausstellung für Ihre Domains liefert, und restriktive CAA-Records mit Account-Bindung zu veröffentlichen.
Halten Sie eine ccTLD, die nur geparkt ist – keine Website, kein Mail? Genau dort bemerkt niemand eine Ausstellung, bis jemand die Domain benutzt. CT-Log-Monitoring kostet im Betrieb nichts und deckt genau diesen Fall ab.
Die SaaS-Subdomain-Falle: ein CAA-Record, viele Hostnamen
CAA-Records sind die deklarative Ausstellungs-Sperre: Nur die dort genannten Zertifizierungsstellen dürfen für Ihre Domain ausstellen. Der Haken: Ein Record auf der Apex-Domain gilt für die Domain und alle Subdomains darunter. Bei der Ausstellung läuft die Stelle die Kette von unten nach oben ab – für shop.beispiel.de prüft sie shop.beispiel.de, dann beispiel.de – und stoppt beim ersten gefundenen CAA-Record.
Daraus entsteht die stillste Fehlerquelle des ganzen Themas: Wenn auf Ihrer Apex ein CAA-Record nur Let’s Encrypt erlaubt, Ihr Shop aber auf einer SaaS-Subdomain läuft, deren Anbieter eine andere CA nutzt, scheitert deren Renewal – nachts, auf einem System, das Sie nicht administrieren, mit einer Fehlermeldung, die bei Ihnen nie ankommt. Sobald das Zertifikat abläuft, sperrt der Browser die Subdomain für Ihre Kunden.
Vor jeder Änderung gilt: lesen und notieren, was heute da steht.
dig +short CAA beispiel.de
dig +short CAA shop.beispiel.deDie Lösung ist ein Bestand pro Hostnamen und – wo nötig – ein eigener CAA-Record auf der Subdomain, der die CA des Anbieters nennt; Subdomain-Records überschreiben den übergeordneten:
beispiel.de. 3600 IN CAA 0 issue "letsencrypt.org"
shop.beispiel.de. 3600 IN CAA 0 issue "ca.beispiel-saas.de"Account-gebundene CAA-Records ab dem 15. März 2027
RFC 8657 macht CAA-Records genauer: Der Parameter accounturi muss ein URI sein, der ein konkretes Konto einer Zertifizierungsstelle identifiziert. Ab dem 15. März 2027 müssen CAs diesen Parameter verarbeiten. Praktisch heißt das: Selbst wer eine in Ihrem CAA-Record erlaubte Stelle täuscht, kommt nicht an ein Zertifikat, wenn es nicht an genau Ihrem Konto hängt. Google nennt diese Account-Bindung als eine der Verteidigungen gegen die September-Angriffe.
Zwei Vorsichtsregeln: Veröffentlichen Sie accounturi erst, wenn Sie sicher sind, welche Konto-URI Ihr ACME-Client nutzt – ein falscher URI blockiert Ihr eigenes Renewal. Und ändern Sie einen Record nach dem anderen, kopieren Sie den alten Wert und rechnen Sie mit der TTL, bevor der Cache umspringt.
beispiel.de. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"Chrome 154 macht schlampiges TLS für Besucher sichtbar
Der dritte Termin im Bündel betrifft die Nachfrage-Seite: Chrome schaltet auf HTTPS-First um. Seit April 2026 (Chrome 147) gilt „Always Use Secure Connections“ für die Nutzer mit Enhanced Safe Browsing – nach Googles Angaben über eine Milliarde Menschen. Mit Chrome 154 im Oktober 2026 wird der Modus für alle Nutzer zur Voreinstellung.
In diesem Modus versucht Chrome jede Verbindung zuerst über HTTPS und fragt vor dem ersten Aufruf einer öffentlichen Seite ohne HTTPS nach, ob der Nutzer wirklich fortfahren will. Für Sie als Betreiber heißt das: Der Warnschirm steht zwischen Ihrer HTTP-Seite und Ihrem Besucher.
Heimtückisch sind Redirect-Ketten: Verträgt auch nur ein einziger Hops der Kette kein HTTPS, sehen Nutzer die Warnung – selbst wenn das Ziel selbst sauber über HTTPS läuft. Die Entscheidung eines Nutzers, trotzdem fortzufahren, merkt sich Chrome für die Dauer der Sitzung. Wer also über http://-Kurzlinks, ältere Kampagnen-URLs oder eine www-Umleitung arbeitet, sollte die komplette Kette einmal durchprobieren.
HSTS hilft – aber nur begrenzt: Der Header erklärt einen Host zum HTTPS-only-Host, sodass Chrome bei ihm nie mehr auf HTTP zurückfällt. Er schützt aber genau den Host, der ihn setzt – nicht die anderen Hops der Kette und nicht eingebettete Ressourcen, die noch über HTTP kommen. Wer HSTS einführen will, startet ohne Preload-Eintrag und prüft erst, dass die Seite vollständig über HTTPS ausgeliefert wird. Googles Rat an Betreiber ist trotzdem eindeutig: HTTPS heute flächig aktivieren, nicht erst mit Chrome 154. Ausgenommen sind private Adressen – lokale IPs, Single-Label-Hostnamen, Intranet-Kurzlinks.
Die Zertifikats-Hygiene-Checkliste: neun Punkte, ein Nachmittag
Diese neun Punkte passen in einen Nachmittag, wenn der Bestand aktuell ist. Was sich automatisieren lässt und was menschliche Augen braucht, steht bei jedem Punkt dabei – die automatisierbaren Punkte laufen in der Website-Pflege für die von uns betreuten Websites dauerhaft mit.
- Bestand aufnehmen: jeden Hostnamen mit Zertifikat auflisten, inklusive SaaS-Subdomains, die ein Anbieter in Ihrem Namen erneuert. Manuell – kein Skript weiß, wer für wen ausstellt.
- Renewal-Rhythmus prüfen: Cronjobs, Wrapper-Skripte und Runbooks nach festen Werten durchsuchen – 83, 80 und 60 sind die typischen Kandidaten – und auf rund zwei Drittel der Lebensdauer umstellen, Tag 42 bei 64 Tagen. Der grep läuft automatisch, die Entscheidung ist manuell.
- ARI klären: Ein ACME-Client, der ARI auswertet, braucht keine Änderung; ein Client ohne ARI braucht Punkt 2.
- Ab dem 14. Oktober 2026 gegen Staging proben: Jeder Renewal-Fehler dort kostet nichts und sagt Ihnen alles über den Februar. Automatisierbar.
- Ablaufdaten monitoren statt Statuscodes zählen: Ein 200 beweist nur, dass der Server geantwortet hat – der Ablauf-Check mit openssl gehört in die Überwachung. Automatisierbar.
- CAA-Bestand lesen: dig +short CAA auf Apex und Subdomains, Werte notieren und kopieren, bevor irgendetwas geändert wird. Lesen automatisierbar, Auswertung manuell.
- SaaS-Subdomain absichern: eigenen CAA-Record auf der Subdomain setzen, wenn deren CA nicht in der Apex-Liste steht – mit dem Anbieter abstimmen. Manuell.
- CT-Log-Monitoring einrichten: zuerst für geparkte Domains und ccTLDs, dort bemerkt sonst niemand eine Ausstellung. Einmal eingerichtet, danach automatisch.
- HTTPS-Kette komplett prüfen: jeden Redirect-Hop und jede eingebettete Ressource durchprobieren; HSTS für den eigenen Host erwägen – ohne Preload. Kette per Skript, Bewertung manuell.
Ehrlich zum Aufwand: Die Punkte 4, 5 und 8 sind nach dem Einrichten laufende Automatik; die Punkte 1, 2 und 7 brauchen einen Menschen, der die Liste mit Leben füllt. Das Nachmittag-Argument gilt für einen gepflegten Bestand – bei vielen verstreuten Subdomains und mehreren Anbietern wird es ein Tag.
Wenn Sie den Nachmittag nicht haben: Renewal-Automatik, Ablauf-Monitoring und Zertifikats-Bestand sind genau der Teil der Arbeit, den wir in der Website-Pflege übernehmen. Sprechen Sie uns an – wir machen Ihnen einen Festpreis.