Let's Encrypt 64 Tage: kürzere Zertifikate ab 2027

Let's Encrypt verkürzt die Laufzeit seiner Zertifikate: Ab dem 10. Februar 2027 stellt die grösste Zertifizierungsstelle des Netzes standardmässig nur noch Zertifikate mit 64 Tagen Gültigkeit aus, statt wie bisher 90. Das hat Let's Encrypt am 7. Oktober 2026 in einem Blogbeitrag bestätigt, und in der Testumgebung gilt die neue Laufzeit schon ab übermorgen, dem 14. Oktober. Wer zuletzt unsere Anleitung zu mTLS mit Caddy gelesen hat, kennt das Muster bereits: Let's Encrypt hat dort im Juli die Client-Zertifikate endgültig gestrichen, jetzt schrumpft die Laufzeit der Server-Zertifikate.

Für die meisten Server ist das kein Drama, sofern die Erneuerung wirklich automatisch läuft. Für alle, bei denen irgendwo eine feste Zahl in einem Cronjob steht, ist es eine Frist. Diese Meldung sortiert, was sich wann ändert, welche verbreiteten ACME-Programme damit klarkommen und wo es eng wird.

Let's Encrypt 64 Tage: die Termine im Überblick

Ganz neu ist der Plan nicht. Bereits am 2. Dezember 2025 hatte Let's Encrypt den Weg von 90 auf 45 Tage angekündigt, mit einem Zwischenschritt über 64 Tage. Neu ist, dass die Termine jetzt verbindlich bestätigt sind und der Testbetrieb deutlich früher beginnt als damals in Aussicht gestellt. Die Daten im Einzelnen:

• Seit 13. Mai 2026: Wer will, kann über das Profil tlsserver bereits 45 Tage gültige Zertifikate beziehen. Das ist freiwillig und für Frühstarter gedacht.
• 14. Oktober 2026: Die Testumgebung (Staging) stellt auf 64-Tage-Zertifikate um, und zwar mit genau dem Verhalten, das ab Februar in der Produktion gilt. Das bestätigt ein Mitarbeiter von Let's Encrypt im Community-Forum.
• 10. Februar 2027: Das Standardprofil classic liefert nur noch 64 Tage. Gleichzeitig sinkt die Zeit, während der eine erfolgreiche Domainprüfung wiederverwendet werden darf, von 30 auf 10 Tage.
• Um den 11. Mai 2027: Das letzte 90-Tage-Zertifikat läuft voraussichtlich ab. Gültige Zertifikate werden laut Let's Encrypt im Zuge der Umstellung nicht widerrufen.
• 16. Februar 2028: Das Standardprofil sinkt auf 45 Tage, die Wiederverwendung einer Domainprüfung auf sieben Stunden.

Unverändert bleiben nach Angaben von Let's Encrypt die Rate Limits, die ACME-Adressen und die Zertifikatskette. Zu den Rate Limits hatte Let's Encrypt schon im Februar einen eigenen Beitrag veröffentlicht: Erneuerungen zählen nicht auf die Grenzen für neue Zertifikate, also ändert die häufigere Erneuerung daran nichts.

Was gegenüber Dezember neu ist

Im Dezember hiess es noch, jede Änderung erreiche die Testumgebung etwa einen Monat vor der Produktion. Jetzt sind es fast vier Monate. Das ist die eigentlich nützliche Nachricht dieser Woche: Wer seine Erneuerung, seine Reload-Skripte und seine Überwachung gegen echte 64-Tage-Zertifikate prüfen will, kann das ab dem 14. Oktober tun und muss nicht bis Januar warten. Ausserdem nennt die Mitteilung zum ersten Mal ein konkretes Ablaufdatum für die letzten 90-Tage-Zertifikate.

Warum die Zertifikate kürzer werden

Let's Encrypt handelt nicht aus eigenem Antrieb. Im April 2025 hat das CA/Browser Forum, in dem sich Zertifizierungsstellen und Browserhersteller auf gemeinsame Regeln einigen, den Antrag SC081v3 angenommen. Er senkt die höchstzulässige Laufzeit öffentlich vertrauter Zertifikate schrittweise von 398 auf 47 Tage und die Wiederverwendung einer Domainprüfung von 398 auf 10 Tage. Begonnen hat das im März 2026, abgeschlossen ist es im März 2029. Die Zwischenschritte fasst der DNS-Anbieter DNSimple übersichtlich zusammen: höchstens 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Alle vier grossen Browserhersteller, Apple, Google, Microsoft und Mozilla, haben zugestimmt, keine Zertifizierungsstelle hat dagegen gestimmt.

Die Begründung ist nüchtern. Ein Zertifikat, dessen Schlüssel gestohlen wurde, bleibt bis zu seinem Ablauf gültig, wenn der Widerruf nicht greift, und der Widerruf greift in der Praxis schlecht. Je kürzer die Laufzeit, desto kürzer das Zeitfenster für Missbrauch. Let's Encrypt schreibt dazu im Dezemberbeitrag, kürzere Laufzeiten begrenzten den Schaden einer Kompromittierung und machten den Widerruf wirksamer.

Bemerkenswert ist das Tempo. Let's Encrypt lag mit 90 Tagen schon immer weit unter den Branchenregeln und bleibt das auch: Die 64 Tage greifen einen Monat, bevor die 100-Tage-Grenze überhaupt in Kraft tritt. Kommerzielle Anbieter, die früher Jahreszertifikate verkauften, mussten schon im März 2026 auf 200 Tage herunter und dürfen ihren Kunden ab März 2027 erklären, warum das Produkt nach 100 Tagen erneuert werden muss. Das ist allerdings nicht euer Problem.

Wann certbot, acme.sh und Caddy erneuern

Ob die Umstellung euch etwas angeht, hängt fast nur davon ab, wie euer ACME-Programm den Erneuerungszeitpunkt bestimmt. Es gibt drei Verfahren: einen festen Abstand vor dem Ablauf, einen Anteil der Laufzeit, oder die Frage an die Zertifizierungsstelle selbst. Für Letzteres gibt es seit Juni 2025 den Standard RFC 9773, ACME Renewal Information (ARI): Der Server nennt dem Client ein Zeitfenster, in dem er erneuern soll. Let's Encrypt bietet ARI seit März 2023 an.

Caddy: erledigt sich selbst

Caddy unterstützt ARI seit Version 2.8 und zieht es zusammen mit Laufzeit und Widerrufsstatus heran, um eine Erneuerung auszulösen. Wer Caddy nach unserer Anleitung zum Caddy Reverse Proxy betreibt, muss nichts ändern.

certbot: die Version entscheidet

Bei certbot kommt es darauf an, welche Fassung eure Distribution mitliefert. Bis Version 3 erneuerte certbot fest 30 Tage vor Ablauf. Version 4.0 vom 8. April 2025 stellte auf ein Drittel Restlaufzeit um, Version 4.1 vom 10. Juni 2025 fragt zusätzlich ARI ab und erneuert bei Let's Encrypt laut Changelog typischerweise nach rund zwei Dritteln der Laufzeit.

Debian 12 liefert certbot 2.1.0, Debian 13 die Version 4.0.0, so steht es im Debian-Paketverfolger. Ubuntu 24.04 hat certbot 2.9.0. Alle drei kommen mit 64 Tagen zurecht: Die alte 30-Tage-Regel erneuert ein 64-Tage-Zertifikat nach 34 Tagen, die Drittel-Regel nach rund 43 Tagen. Auch bei 45 Tagen im Jahr 2028 bleibt genug Puffer. Wer certbot mit dem vom Paket mitgelieferten Timer betreibt, ist also auf der sicheren Seite, solange niemand die Vorgabe mit einem eigenen renew_before_expiry verbogen hat.

acme.sh: hier wird es eng

Anders sieht es beim reinen Shell-Skript acme.sh aus. Laut der Handbuchseite in Debian 13 erneuert acme.sh standardmässig 60 Tage nach der Ausstellung, gesteuert über --days. ARI beherrscht es noch nicht, das schreibt der Hauptentwickler selbst in Issue 6633 und empfiehlt dort für kurzlebige Zertifikate, --days von Hand anzupassen.

Durchgerechnet bleiben bei einem 64-Tage-Zertifikat noch vier Tage zwischen dem ersten Erneuerungsversuch und dem Ablauf. Das reicht, solange nichts schiefgeht. Fällt die Erneuerung über ein langes Wochenende aus, weil der DNS-Anbieter klemmt oder Port 80 kurz zu ist, steht das Zertifikat abgelaufen da. Ab 2028, mit 45 Tagen, kommt der Erneuerungsversuch nach 60 Tagen schlicht zwei Wochen zu spät. Wer acme.sh nutzt, setzt --days deshalb jetzt auf einen Wert um 40, für jedes Zertifikat einzeln.

Dass es auch anders geht, zeigt pfSense: Das ACME-Paket dort hatte dasselbe Problem mit einem festen 60-Tage-Abstand und erneuert seit Version 1.1 standardmässig nach zwei Dritteln der Laufzeit. Das Paket ist für pfSense Plus 25.11.1 und CE 2.8.1 erschienen.

Selbst geschriebene Skripte und Cronjobs

Die grösste Gefahr steckt nicht in den bekannten Programmen, sondern in Eigenbauten: dem Skript, das alle 60 Tage --force-renewal auslöst, oder dem Überwachungscheck, der erst bei 80 Tagen Alter Alarm gibt. Let's Encrypt rät ausdrücklich dazu, Cronjobs, Hilfsskripte und Betriebsanleitungen nach typischen fest eingetragenen Werten wie 83, 80 oder 60 zu durchsuchen. Ein Skript, das erst nach 80 oder 83 Tagen erneuert, kommt bei 64 Tagen schlicht zu spät. Ohne ARI empfiehlt Let's Encrypt, nach ungefähr zwei Dritteln der Laufzeit zu erneuern.

Eine Sache, die viele noch im Kopf haben, gibt es übrigens nicht mehr: die Warn-E-Mail vor dem Ablauf. Let's Encrypt hat diesen Dienst am 4. Juni 2025 eingestellt. Wer sich darauf verlassen hat, ist seit über einem Jahr ohne Netz unterwegs. Auch unsere ältere Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver geht noch davon aus, dass diese Mail kommt.

Die kürzere Wiederverwendung der Domainprüfung

Der zweite Teil der Änderung fällt weniger auf. Bisher durfte Let's Encrypt eine erfolgreiche Domainprüfung 30 Tage lang für weitere Zertifikate wiederverwenden, ab Februar sind es 10 Tage. Wer die Erneuerung voll automatisch erledigt, merkt davon laut Let's Encrypt nichts, ausser der Client ist ausdrücklich darauf gebaut, sich auf die Wiederverwendung zu verlassen. Betroffen sind vor allem Setups mit DNS-Challenge, bei denen der TXT-Eintrag von Hand gesetzt wird. Für sie hat Let's Encrypt im Februar das Verfahren DNS-PERSIST-01 angekündigt, bei dem ein dauerhafter TXT-Eintrag ein bestimmtes ACME-Konto berechtigt. Der Produktivstart war für das zweite Quartal 2026 angepeilt; ob er erfolgt ist, sagt die aktuelle Mitteilung nicht.

Was ihr bis Februar prüfen solltet

Das meiste davon ist eine Sache von zehn Minuten pro Server. Die Reihenfolge ist so gewählt, dass ihr nach dem ersten Punkt bereits wisst, ob der Rest euch überhaupt betrifft.

1. Herausfinden, welcher Client erneuert. Bei certbot zeigt certbot --version die Fassung, bei acme.sh acme.sh --version. Läuft Caddy, ist der Punkt erledigt.
2. Feste Zahlen suchen. Durchsucht Cronjobs und systemd-Units nach Erneuerungsabständen. Ein grober erster Durchgang, der alle Zeilen mit den von Let's Encrypt genannten Werten zeigt:

sudo grep -rnwE '60|80|83' /etc/cron* /etc/systemd/system /var/spool/cron 2>/dev/null

Nicht jeder Treffer hat mit Zertifikaten zu tun, eine Minutenangabe von 60 ist harmlos. Gesucht sind Zeilen, in denen certbot, acme.sh, --days, --force-renewal oder ein eigenes Erneuerungsskript vorkommt.

3. Ab dem 14. Oktober gegen Staging testen. certbot holt mit --dry-run laut Handbuchseite ein Testzertifikat von der Staging-Umgebung, ohne es zu speichern. Das prüft, ob die Challenge durchläuft:

sudo certbot renew --dry-run

4. Die Laufzeit des aktuellen Zertifikats ansehen. So seht ihr, wann es ausgestellt wurde und abläuft. Den Domainnamen ersetzt ihr durch euren:

sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/cloud.example.ch/cert.pem

5. acme.sh umstellen. Setzt --days beim nächsten Ausstellen auf einen Wert um 40, damit auch bei 45 Tagen im Jahr 2028 Puffer bleibt.
6. Eine Ablaufwarnung einrichten, die nicht von Let's Encrypt kommt. Die Mail gibt es nicht mehr. Eine eigene Prüfung per systemd-Timer mit Benachrichtigung bei Fehlschlag haben wir in der Anleitung systemd-Timer statt Cronjob beschrieben; openssl x509 -checkend mit einer Sekundenzahl ist dafür der passende Baustein.
7. Den Reload nicht vergessen. Ein erneuertes Zertifikat nützt nichts, wenn der Webserver weiter das alte ausliefert. Bei certbot erledigt das ein Deploy-Hook, bei Diensten mit eigener Zertifikatskopie (Mailserver, Datenbanken, NAS) muss die Kopie nach jeder Erneuerung neu verteilt werden. Wer nach zwei Dritteln der Laufzeit erneuert, tut das bei 64 Tagen rund achtmal im Jahr statt wie bisher rund sechsmal.

Fazit: 64 Tage bestrafen nur Handarbeit

Für einen sauber automatisierten Server ändert der 10. Februar 2027 nichts, ausser dass im Log etwas öfter eine Erneuerung steht. Caddy, aktuelle certbot-Fassungen und alles, was ARI spricht, regeln das selbst. Selbst die alten certbot-Versionen in Debian 12 und Ubuntu 24.04 kommen mit ihrer starren 30-Tage-Regel durch.

Treffen wird es die Stellen, an denen ein Mensch einmal eine Zahl eingetragen hat und seither niemand mehr hingesehen hat: das acme.sh mit 60 Tagen, das Skript mit erzwungener Erneuerung, das NAS, auf das jemand das Zertifikat von Hand kopiert. Genau darauf zielt die Branche, und es fällt schwer, ihr zu widersprechen. Ein Zertifikat, das ein Jahr hält, verzeiht vergessene Automatisierung; eines, das 64 Tage hält, deckt sie auf. Wer die Testumgebung ab dem 14. Oktober nutzt, findet diese Stellen im Herbst statt an einem Februarmorgen, an dem die Nextcloud plötzlich eine rote Warnseite zeigt.

Quellen und weiterführende Links

• Let's Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027, Ankündigung vom 7. Oktober 2026
• Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days, Zeitplan vom 2. Dezember 2025
• Let's Encrypt: Profiles, Profile classic, tlsserver und shortlived
• Let's Encrypt: Rate Limits and 45-Day Certificates, Februar 2026
• Let's Encrypt Community: Staging-Termin für die 64-Tage-Zertifikate
• Let's Encrypt: Expiration Notification Service Has Ended
• Let's Encrypt: DNS-PERSIST-01, Ankündigung vom 18. Februar 2026
• Let's Encrypt: Upcoming Features, Stand der Funktionen inklusive ARI
• CA/Browser Forum: Ballot SC081v3, Beschluss und Abstimmungsergebnis
• DNSimple: SSL Certificate Validity Changes (2026–2029), Zwischenschritte des Zeitplans
• RFC 9773: ACME Renewal Information (ARI) Extension
• Certbot 4.0.0 und Certbot 4.1.0, Changelogs zu Erneuerungszeitpunkt und ARI
• Debian-Paketverfolger: python-certbot und Ubuntu-Paket certbot in 24.04
• certbot(1) und acme.sh(1), Handbuchseiten in Debian 13
• acme.sh Issue 6633, Aussage des Entwicklers zu fehlender ARI-Unterstützung
• Caddy v2.8.0 Release Notes, ARI-Unterstützung
• pfSense Redmine 16603, Erneuerung nach zwei Dritteln der Laufzeit im ACME-Paket 1.1