64 Tage Laufzeit ab Februar 2027: Was Let's Encrypt ändert und was die eigenen Erneuerungsregeln dazu aushalten

Let's Encrypt hat am 7. Oktober 2026 angekündigt, ab 10. Februar 2027 nur noch Zertifikate mit 64 Tagen Laufzeit auszustellen, sofern man nicht ausdrücklich ein noch kürzeres Profil wählt. Der Satz, der für den Betrieb zählt, steht direkt dahinter: Automatisch erneuernde Clients mit ACME Renewal Information (ARI) sind damit durch. Wer hartcodiert nach Tagen ab Ausstellung rechnet, soll auf ungefähr zwei Drittel der Laufzeit umstellen.

Der Zeitpunkt für den Test ist nicht 2027. In der Ankündigung steht, dass die Staging-Umgebung am 14. Oktober 2026 auf die Ausgabe von 64-Tage-Zertifikaten umschaltet. Für alle, die eine eigene ACME-Strecke oder eine selbst gebaute Erneuerungsroutine haben, ist diese Woche der richtige Termin für den Probelauf.

Was sich ändert und was gleich bleibt

Die Zahl aus der Ankündigung im Einzelnen:

• Ab 10. Februar 2027 haben alle ausgestellten und erneuerten Zertifikate 64 Tage Laufzeit, außer man wählt 45 oder 6 Tage.
• Das letzte Zertifikat mit 90 Tagen läuft nach Let's-Encrypt-Rechnung am 11. Mai 2027 ab.
• Gültige Zertifikate werden für die Umstellung nicht widerrufen.
• Die Staging-Umgebung stellt am 14. Oktober 2026 um.
• Der Authorization-Reuse sinkt von 30 auf 10 Tage, 2028 auf sieben Stunden.
• Die ACME-Endpunkte, die Issuance-Ketten und die Rate Limits bleiben unverändert.

Der Grund für die kurze Laufzeit heißt Risikoreduktion: Weniger Zeit mit einem kompromittierten Schlüssel, weniger Zeit, in der eine Fehlausgabe wirkt. Für die Validierungsseite kommt ein zweiter Grund dazu. Solange Wiederverwendungsfristen lang sind, muss eine ausstellende Stelle bei älterem Validierungsmaterial die CAA-Einträge der Domain nachprüfen. Bei sieben Stunden Reuse-Frist entfällt diese Nachprüfung praktisch, weil sie teurer wäre als die neue Validierung.

Die eigentliche Vorlage steht beim CA/B Forum

Wer sich auf die Let's-Encrypt-Meldung beschränkt, hält 64 Tage für eine Entscheidung dieses Ausstellers. In Section 6.3.2 der TLS Baseline Requirements steht die Stufung, die dahinterliegt: 398 Tage für Ausstellungen vor dem 15. März 2026, 200 Tage bis zum 15. März 2027, 100 Tage bis zum 15. März 2029 und 47 Tage ab dem 15. März 2029. Eingeführt wurde die Stufung mit Ballot SC081, angenommen am 11. April 2025, wirksam mit Version 2.1.5 der Requirements zum 16. Mai 2025. Wir haben das an den veröffentlichten Requirements v2.3.1 nachgelesen und die Tabelle Zeile für Zeile mit dem Text abgeglichen.

Dabei fällt eine Zahl auf, die in vielen Artikeln mitlaufen dürfte: 460 Tage. Diese Obergrenze gehört in die Code-Signing-Baseline-Requirements. Für TLS-Zertifikate gilt sie nicht. Im TLS-Requirementsdokument v2.3.1 kommt die Zeichenkette 460 null Mal vor. Ein Runbook mit "maximal 460 Tage" zitiert damit das Regelwerk für Code-Signing.

Die zweite Stufung, die in der Praxis mehr wehtut, betrifft die Wiederverwendung von Validierungsdaten nach Section 4.2.1: 398 Tage, dann 200, dann 100 und ab 15. März 2029 zehn Tage. Genau diese Kurve begründet den Sprung von 30 auf 10 Tage Authorization-Reuse bei Let's Encrypt und die sieben Stunden für 2028.

Der Engpass ist nicht die Laufzeit, sondern das Erneuerungsfenster

Ein Zertifikat, das nach 64 Tagen abläuft, ist nur so sicher wie die Routine, die es erneuert. ACME Clients entscheiden heute selbst, wann sie erneuern. RFC 9773, standardisiert im Juni 2025, dreht die Richtung um: Der Client fragt die renewalInfo des Ausstellers ab und wählt eine gleichverteilte Zufallszeit im vorgeschlagenen Fenster. Wörtlich heißt es dort, Clients müssten zu einem Zeitpunkt ihrer Wahl auf Basis des vorgeschlagenen Fensters erneuern, und für cron-basierte Clients könne es nötig sein, die Laufhäufigkeit zu erhöhen.

Wir haben für die verbreiteten Clients in deren Dokumentationen, Release-Hinweisen und Quelltexten nachgemessen, nach welcher Regel erneuert wird und ob ARI schon drinsteckt.

Rechnet man diese Regeln auf 64 Tage Laufzeit, erscheinen zwei Gruppen. Die Verhältnis-Regler, also Caddy, Certbot ab 4.0, lego, nginx-acme und Stalwart, verkleinern den Puffer proportional und landen bei rund 21 Tagen Rest. Die Clients mit fixem Fenster behalten ihre 30 Tage und erneuern dann schlicht früher, nur mit kleiner werdendem Abstand zur Grenze. Eng wird es bei den starr kleinen Fenstern: HAProxy startet die Erneuerung bei einem Zwölftel der Laufzeit, das sind bei 90 Tagen 7,5 Tage und bei 64 Tagen 5,3 Tage, und der Scheduler wacht ohnehin nur alle zwölf Stunden auf. lua-resty-acme fährt mit starren sieben Tagen, was bei 64 Tagen elf Prozent Laufzeit entspricht.

Traefik steht zwischen den Gruppen. Die Doku nennt 30 Tage vor Ablauf und verweist für abweichende Laufzeiten auf certificatesDuration, dessen Default 2160 Stunden beträgt. Stellt man diese Option auf die neue Lebensdauer um, greift Traefiks eigene Stufentabelle, und der Puffer springt von 30 auf 10 Tage. Ein ARI-Aufruf ist in den Release-Hinweisen der letzten 100 Traefik-Releases nicht auffindbar, obwohl in deren go.mod lego v5.5.2 steht und lego ARI seit v4.12.0 kann. Festhalten lässt sich das als Befund aus Release-Hinweisen, Abhängigkeitsliste und Konfigurationsdoku, ein Herstellerstatement dazu liegt nicht vor.

Selbstcheck: Was unsere eigene Strecke zeigt

Wir haben am 13. Oktober 2026 alle Hostnamen aus dem Caddy-Frontend unserer Homelab-Domäne einzeln per TLS abgefragt. 27 Namen stehen in der Konfiguration, 26 haben geantwortet, einer war von diesem Netz aus nicht erreichbar. Ergebnis: alle 26 antwortenden Endpunkte liefern ein Zertifikat von Let's Encrypt, alle mit exakt 90 Tagen Gültigkeit, Restlaufzeit zwischen 36 und 88 Tagen, Median 85 Tage. Ablaufverteilung: acht Namen im November 2026, fünf im Dezember 2026, dreizehn im Januar 2027. An einem Frontend hängen 33 gespeicherte Let's-Encrypt-Zertifikate. Rechnerisch heißt das: Nach der Umstellung erneuert dasselbe Frontend 2027 pro Name rund alle zwei Monate statt rund alle vier.

Der zweite Strang ist die Firmen-Strecke. Dort liefert nginx-proxy-manager 2 mit gebundeltem certbot, gemessen Version 5.8.0, also deutlich jenseits der ARI-Version 4.1.0. Alle 32 aktiven Proxy-Konfigurationen zeigen auf dasselbe certbot-verwaltete Wildcard-Zertifikat im ACME-Store, Gültigkeit gemessen 30. September bis 29. Dezember 2026. Auf dem Homelab-Edge läuft Caddy v2.11.4, im Binary finden sich renewalInfo und suggestedWindow als Zeichenketten, das ARI-Feature ist seit v2.8.0 an Bord. Auf beiden Edges gibt es keinen cron-basierten Erneuerungsjob, keine certbot-, lego- oder acme.sh-Installation im PATH und keinen systemd-Timer mit Zertifikatsbezug. Die Erneuerung läuft dort also vollständig ACME-getrieben, was die Gruppe der Clients trifft, für die Let's Encrypt sagt, sie seien durch.

Zwei Funde aus demselben Scan gehören trotzdem in die Liste. Im Ordner für manuell hochgeladene Zertifikate der Firmen-Strecke liegt ein Sectigo-Wildcard-Zertifikat für dieselbe Domain, ausgestellt am 18.08.2025 und abgelaufen am 23.04.2026, daneben ein manuell abgelegtes Let's-Encrypt-Zertifikat mit Ablauf 22.12.2026. Kein einziger aktiver Proxy-Host verweist auf diese Dateien, nur deaktivierte Konfigurationen und Backupdateien aus August und September tun es. Totes Material, das nur beim nächsten Aufräumen auffällt, weil kein Browser dagegen meckert.

Der Bereich, den wir nicht messen konnten, ist die interne Seite. Die Virtualisierungs-Hosts waren aus diesem Netz per SSH nicht erreichbar, die Admin-Ports der internen Systeme liefern von hier keine TLS-Handshakes. Proxmox hängt bei uns hinter dem Edge-Proxy mit insecure auf die Node-Ports 8006 und 8007, das sichtbare Zertifikat kommt also vom Frontend und wurde oben gezählt. Wie lang die Node-Zertifikate intern laufen und wer sie erneuert, ist in dieser Messung offen. Genau das ist der Punkt, an dem die meisten Flotten eine Lücke haben, weil der Browser nie meckert. Ein zweites, ganz anderes Muster läuft bei uns auf Windows-Update und Zertifikatsrotation 2027: dort erneuert kein ACME-Client, sondern ein Betriebssystem zieht neue Signaturzertifikate nach.

Was Betreiber in der Diskussion sagen

Die Ankündigung lief auf Hacker News in zwei Einreichungen, die größere mit 59 Punkten und 28 Kommentaren (Thread), die zweite mit 18 Punkten und 10 Kommentaren (Thread). Wir geben die Argumente sinngemäß wieder, es sind Meinungen einzelner Kommentierender und keine Belege.

Zustimmung kommt mit zwei Begründungen. Kürzere Laufzeiten zwingen Betriebe zur Automatisierung, die bei großen Organisationen oft fehle, und sie begrenzen den Schaden gestohlener Schlüssel, weil gefälschte Zertifikate in den Transparenzlogs auffallen und ein langlebiges gestohlenes Zertifikat schwer zu widerrufen ist. Kritik zielt auf den Prozess: Browserhersteller steuerten das CA/B Forum, der Nutzen kurzer Laufzeiten sei gegen einen übernommenen Domain-Registrar begrenzt, und Geräte mit alten Oberflächen seien schwer zu automatisieren. Eine praktische Anmerkung betrifft die Erprobung: Es gebe noch kein ACME-Profil, mit dem man 64 Tage vorab anfordern könne. Das ist eine Aussage aus dem Thread, die wir nicht bestätigen konnten; die dokumentierten Profile sind classic mit 90, tlsserver mit 45 und shortlived mit 6 Tagen. Die Frage, warum gerade 64 Tage, beantworten Kommentierende mit „zwei lange Monate plus Puffer". Eine Begründung des Projekts dazu haben wir nicht gefunden.

Unabhängig davon berichteten SecurityWeek und Help Net Security, ohne zusätzliche Fakten gegenüber der Ankündigung.

Checkliste für den Staging-Test

1. Client und Version festhalten und gegen die Tabelle oben prüfen. Ein Certbot 3.x erneuert nach fix 30 Tagen, ein Certbot ab 4.1 nach ARI.
2. In cron-Jobs, Wrapper-Skripten und Runbooks nach den Zahlen 83, 80 und 60 suchen. Diese Empfehlung stammt wörtlich aus der Ankündigung, weil diese Zahlen harte Abstände von der Ausstellung meinen.
3. Im Testsignal die 64-Tage-Laufzeit erzwingen, gegen die Staging-Umgebung, die seit dem 14. Oktober 64 Tage ausstellt. Prüfen, ob der Client wirklich im neuen Fenster erneuert und nicht erst nach Ablauf.
4. Reload und Alarmierung nachweisen. Eine Erneuerung, die niemandem auffällt, wenn sie scheitert, ist die Hälfte der Arbeit. Eine Alarmierung allein auf Restlaufzeit feuert bei 64 Tagen Laufzeit doppelt so oft.
5. Interne und selbst signierte Zertifikate einzeln auflisten, weil sie von keiner ACME-Regel erfasst werden. Bei Proxmox greift für ACME-Zertifikate die 30-Tage-Regel über pve-daily-update, für Zertifikate der hauseigenen PVE-CA ein eigener Zweig mit 14 Tagen Restlaufzeit oder Gültigkeit über zwei Jahre.
6. Für Monitoring-Integrationen den Durchsatz einplanen. Kürzere Laufzeiten bedeuten mehr Ausstellungen, mehr Reloads und mehr Messpunkte pro Jahr.

Grenzen dieser Messung

Die Ankündigung steht unter letsencrypt.org/2026/10/07/64-day-certs. Beim Messlauf war diese Seite aus unserem Netz wiederholt nicht erreichbar, daher haben wir den Volltext aus dem Feed gelesen und am 16. Oktober gegen den Feed erneut abgeglichen. Alle Daten im Beitrag stammen aus dieser Ankündigung. Die ARI-Aussagen zu Traefik, HAProxy und Proxmox beruhen auf nachgewiesener Abwesenheit in Dokumentationen und Release-Hinweisen. Ein Statement der Projekte dazu liegt nicht vor, und ob HAProxy intern trotzdem renewalInfo verarbeitet, bleibt ungemessen. Die internen und selbst signierten Zertifikate der Flotte bleiben offen, weil wir sie aus diesem Netz heraus nicht erreichen.

So haben wir gemessen

Am 13. Oktober 2026 haben wir jeden Hostnamen aus dem Caddy-Frontend einzeln per TLS abgefragt und Aussteller, Gültigkeitsbeginn und -ende des Zertifikats gelesen, 27 Namen, 26 Antworten. Für die Firmen-Strecke lasen wir die Konfiguration des nginx-proxy-manager, das gebündelte certbot und die Zertifikatsablage. Die ACME-Clients haben wir nicht ausprobiert, die Tabelle beruht auf deren Dokumentation, Release-Hinweisen und Quelltexten, mit der Quellenlage in der Tabelle selbst. Die Aussagen, was ein Client nicht kann, sind Befunde aus fehlenden Einträgen, keine Herstellerbestätigung.

Weiterführende Quellen

Primärquellen

• Let's Encrypt, 64-Day Certificate Lifetimes Coming Feb 2027, Ankündigung vom 07.10.2026, Volltext im Feed
• Let's Encrypt, Certificate Profiles, Stand 04.10.2026: classic 90 Tage, tlsserver 45 Tage, shortlived 6 Tage
• Let's Encrypt, FAQ, 90-Tage-Ausstellung, 60-Tage-Erneuerung, Authorization-Reuse
• CA/Browser Forum, TLS Baseline Requirements v2.3.1, Abschnitte 6.3.2 und 4.2.1
• IETF, RFC 9773: ACME Renewal Information (ARI) Extension, Juni 2025

Dokumentation der Clients

• Caddy, Global options mit renewal_window_ratio, Default 0.3333, und Release v2.8.0 mit ARI
• Certbot v4.1.0, ARI-Abruf vom 10.06.2025
• acme.sh, README zu 30 Tagen und ARI
• nginx news, nginx-acme 0.4.0 mit ARI, 20.04.2026
• Traefik, ACME-Resolver, 30-Tage-Regel und certificatesDuration
• HAProxy 3.4, Configuration Manual, Abschnitt ACME scheduler
• Proxmox VE, Administration Guide, ACME-Erneuerung über pve-daily-update
• Stalwart, ACME-Konfiguration, renewBefore als Anteil

Unabhängige Berichte

• SecurityWeek und Help Net Security, 12.10.2026

Community

• Hacker News, 59 Punkte und 28 Kommentare: news.ycombinator.com/item?id=50002249
• Hacker News, 18 Punkte und 10 Kommentare: news.ycombinator.com/item?id=50025513