ACME-Erneuerung testen: 64-Tage-Standard ab Februar 2027

Was sich am 10. Februar 2027 ändert

Die Ankündigung ist knapp und eindeutig. Ab dem 10. Februar 2027 erhalten alle Nutzer von Let's Encrypt standardmäßig Zertifikate mit 64 Tagen Laufzeit, sofern sie nicht ein noch kürzeres Profil mit 45 oder 6 Tagen gewählt haben (Let's Encrypt). Jedes Zertifikat, das ab diesem Tag ausgestellt oder erneuert wird, gilt 64 Tage; das letzte 90-Tage-Zertifikat läuft nach Erwartung der Zertifizierungsstelle am 11. Mai 2027 ab (Let's Encrypt). Bestehende Zertifikate werden nicht widerrufen, und Rate-Limits, ACME-Endpunkte und Zertifikatsketten bleiben unverändert (Let's Encrypt).

Zur Einordnung: Die 64 Tage sind die Vorgabe einer einzelnen Zertifizierungsstelle für ihr Standardprofil classic, keine allgemeine Regel. Die branchenweite Grenze setzen die Baseline Requirements des CA/Browser Forum: Zertifikate, die ab dem 15. März 2027 ausgestellt werden, dürfen höchstens 100 Tage gelten (CA/Browser Forum). Let's Encrypt bleibt darunter und plant den nächsten Schritt: Am 16. Februar 2028 soll das Standardprofil auf 45 Tage sinken (Let's Encrypt). Den gesamten Fahrplan zeichnet der Beitrag zum 200-Tage-Limit und dem Weg dorthin nach; hier geht es um das, was bis Februar zu prüfen ist.

Der Zeitplan bis zum letzten 90-Tage-Zertifikat

Bis zum vollständigen Wechsel laufen zwei Laufzeiten nebeneinander: Bis zum 9. Februar erneuerte Zertifikate gelten noch 90 Tage, danach erneuerte nur noch 64. Ein Bestand mit vielen Hostnamen ist im Frühjahr 2027 gemischt; Auswertungen nach Restlaufzeit müssen beide Längen trennen. Die Stationen im Überblick:

• 14. Oktober 2026: Die Staging-Umgebung stellt 64-Tage-Zertifikate aus, damit Nutzer testen können (Let's Encrypt).
• 10. Februar 2027: Das Standardprofil wechselt in der Produktion auf 64 Tage, die Wiederverwendung einer Autorisierung sinkt von 30 auf 10 Tage (Let's Encrypt).
• 15. März 2027: Neue Zertifikate dürfen branchenweit höchstens 100 Tage gelten (CA/Browser Forum).
• 11. Mai 2027: Das letzte 90-Tage-Zertifikat von Let's Encrypt läuft voraussichtlich ab (Let's Encrypt).
• 16. Februar 2028: Das Standardprofil sinkt auf 45 Tage, die Wiederverwendung einer Autorisierung auf sieben Stunden (Let's Encrypt).
• 15. März 2029: Validierungsdaten für Domainnamen dürfen nach den Baseline Requirements höchstens 10 Tage wiederverwendet werden (CA/Browser Forum).

Für den Prüfplan zählen vor allem die ersten beiden Daten: Wer jetzt in Staging prüft, hat bis Februar Zeit für Korrekturen.

Feste Erneuerungstage finden und ersetzen

Das Risiko ist nicht die kürzere Laufzeit, sondern jede Stelle, an der die alte als feste Zahl hinterlegt ist. Wer den Erneuerungszeitpunkt fest in Tagen hinterlegt hat, soll ihn auf etwa ⅔ der Laufzeit umstellen (Let's Encrypt). Als Suchhilfe nennt Let's Encrypt die Zahlen 83, 80 und 60, die in Cron-Jobs, Hilfsskripten und Betriebshandbüchern stecken können (Let's Encrypt). Die Zahlen erklären sich aus der alten Laufzeit: Bei 90 Tagen bleiben nach 60 Tagen noch 30, nach 80 Tagen noch 10 und nach 83 Tagen noch 7 Tage Restlaufzeit.

Bei einem 64-Tage-Zertifikat kippt diese Rechnung. Eine Regel, die nach 80 oder 83 Tagen erneuert, greift erst, wenn das Zertifikat seit 16 beziehungsweise 19 Tagen abgelaufen ist. Eine Regel mit 60 Tagen lässt 4 Tage Restlaufzeit, kaum genug für einen zweiten Versuch. Auch eine Regel nach Resttagen kann Ärger machen: Wer erneuert, sobald weniger als 70 Tage übrig sind, erneuert ein 64-Tage-Zertifikat bei jedem Lauf. Ohne ARI zählt jeder dieser Aufträge gegen die Grenze von 5 Zertifikaten je identischer Namensliste in 7 Tagen (Let's Encrypt); danach lehnt die Zertifizierungsstelle weitere Zertifikate für diese Namen vorerst ab.

Die Suche ist schnell gemacht; die Ausgabe zeigt typische Treffer als Beispiel:

Die Suche findet Kandidaten, keine Urteile: Eine 60 kann auch ein Timeout in Sekunden sein. Jeder Treffer gehört angesehen, ebenso Konfigurationen von Load Balancern, Einstiegsskripte von Containern und Wiki-Seiten, nach denen von Hand gearbeitet wird. Wie eine ACME-Automatik aufgebaut ist und wo sie typischerweise reißt, beschreibt der Beitrag zur SSL-Automatisierung mit ACME.

Wer bei einem eigenen Skript bleibt, rechnet den Zeitpunkt aus dem Zertifikat statt aus einer Konstante. Das folgende Beispiel für GNU date liest Beginn und Ende der Gültigkeit und stößt die Erneuerung an, sobald zwei Drittel verstrichen sind; es passt für 90, 64 und 45 Tage gleichermaßen:

#!/bin/sh
# Erneuerung anstoßen, sobald zwei Drittel der Laufzeit verstrichen sind.
# Rechnet mit der Laufzeit des Zertifikats selbst, nicht mit festen Tagen.
cert=/etc/ssl/site/fullchain.pem
start=$(date -d "$(openssl x509 -in "$cert" -noout -startdate | cut -d= -f2)" +%s)
end=$(date -d "$(openssl x509 -in "$cert" -noout -enddate | cut -d= -f2)" +%s)
now=$(date +%s)
due=$(( start + (end - start) * 2 / 3 ))
if [ "$now" -ge "$due" ]; then
  exec /usr/local/bin/cert-renew.sh
fi

Den Wechsel jetzt in Staging testen

Let's Encrypt empfiehlt ausdrücklich, vor der Umstellung in der Staging-Umgebung zu testen. Staging ist eine vollständige ACME-Umgebung mit eigener Adresse, https://acme-staging-v02.api.letsencrypt.org/directory, und eigenen Konten: Ein Produktivkonto gilt dort nicht, es braucht ein separates, und die Zertifikate stammen aus einer Test-Hierarchie, der Browser nicht vertrauen.

Ein zweiter Grund für Staging sind die Limits. Fehlversuche in der Produktion kosten Kontingent: Dort sind 5 fehlgeschlagene Autorisierungen je Name, Konto und Stunde erlaubt (Let's Encrypt), in Staging 200 (Let's Encrypt). Neue Aufträge je Konto sind in der Produktion auf 300 in drei Stunden begrenzt (Let's Encrypt), in Staging auf 1500 (Let's Encrypt). Wer einen Client mehrfach umkonfiguriert, bis die Erneuerung sauber läuft, tut das besser dort.

1. Testnamen wählen. Einen Hostnamen oder Testserver verwenden, den keine Besucher aufrufen.
2. Client auf Staging umstellen. Verzeichnisadresse tauschen, ein separates Konto anlegen lassen, sonst nichts ändern, damit derselbe Ablauf wie in der Produktion samt aller Hooks läuft.
3. Zertifikat beziehen und Laufzeit lesen. Beginn und Ende der Gültigkeit mit openssl x509 ausgeben; zwischen beiden müssen 64 Tage liegen.
4. Nächsten Erneuerungstermin ablesen. Der Client oder das eigene Skript sollte um Tag 43 erneuern wollen, nicht bei Tag 60 oder 80. Mit ARI zeigt das vorgeschlagene Fenster den Termin.
5. Erneuerung erzwingen. Eine Erneuerung außer Plan auslösen und prüfen, ob die Validierung erneut durchläuft und alle Folgeschritte greifen: Reload, Kopie auf weitere Server, Neustart anderer Dienste.
6. Zurückstellen und festhalten. Verzeichnisadresse zurück auf die Produktion, Ergebnis mit Datum dokumentieren, damit der Test im Februar nicht wiederholt werden muss.

Der erste Aufruf zeigt, dass das Verzeichnis von Staging die Profile und die Ressource für ARI anbietet (abgerufen am 14. Oktober 2026), der zweite gibt die Gültigkeit eines bezogenen Zertifikats aus (Beispielausgabe):

Wer schon den Stand von 2028 prüfen will, wählt in Staging das Profil tlsserver. Es stellt Zertifikate mit 45 Tagen Laufzeit aus (Let's Encrypt) und begrenzt die Wiederverwendung einer Autorisierung auf sieben Stunden (Let's Encrypt). So lassen sich beide künftigen Verschärfungen in einem Durchgang ausprobieren, sofern der Client die Auswahl eines Profils unterstützt.

ARI: den Zeitpunkt der Zertifizierungsstelle überlassen

Die Ankündigung nennt einen einfachen Fall: Wer automatisiert erneuert und einen Client mit ACME Renewal Information nutzt, sollte bereits gerüstet sein, weil ARI der Zertifizierungsstelle erlaubt, dem Client den Erneuerungszeitpunkt mitzuteilen. Das Verfahren ist als RFC 9773 standardisiert (IETF). Der Client fragt je Zertifikat ein vorgeschlagenes Zeitfenster ab und erneuert darin. Verkürzt sich die Laufzeit, verschiebt sich das Fenster mit, ohne dass jemand eine Zahl ändern muss.

Let's Encrypt empfiehlt, die Erneuerungsinformation je Zertifikat mindestens zweimal täglich abzufragen (Let's Encrypt). Als Rückfallebene, falls ARI nicht greift, soll erneuert werden, wenn noch ein Drittel der Gesamtlaufzeit übrig ist (Let's Encrypt). Ein praktischer Nebeneffekt: Erneuerungen über ARI sind von allen Rate-Limits ausgenommen. Wie ARI bei sehr kurzen Laufzeiten mit dem Monitoring zusammenspielt, beschreibt der Beitrag zu 6-Tage-Zertifikaten und gekoppelten Warnschwellen.

Ob ARI tatsächlich genutzt wird, zeigen die Protokolle des Clients: Abfragen der Adresse renewalInfo aus dem Verzeichnis müssen regelmäßig auftauchen, nicht nur bei der Ausstellung. Fehlen sie, arbeitet der Client mit einer eigenen Regel, und es gilt der Abschnitt über feste Erneuerungstage.

Autorisierung: von 30 auf 10 Tage

Die zweite Änderung zum 10. Februar ist weniger sichtbar. Hat ein ACME-Konto die Kontrolle über einen Namen nachgewiesen, darf es diese Autorisierung für weitere Aufträge wiederverwenden. Diese Frist sinkt von 30 auf 10 Tage (Let's Encrypt) und 2028 auf sieben Stunden (Let's Encrypt). Let's Encrypt begründet das mit der Verschärfung der Baseline Requirements, nach der Validierungsdaten ab dem 15. März 2029 höchstens 10 Tage wiederverwendet werden dürfen (CA/Browser Forum), und mit dem Wegfall der erneuten CAA-Prüfung, die bei Validierungsdaten älter als 7 Stunden sonst fällig wird (Let's Encrypt).

Wer nicht bewusst auf die Wiederverwendung gebaut hat, muss nach Auskunft von Let's Encrypt nichts anpassen. Bei einer Erneuerung um Tag 43 ist die Validierung der vorigen Erneuerung ohnehin längst verfallen, der Client validiert also jedes Mal neu. Betroffen sind Abläufe, die eine Validierung für mehrere Zertifikate oder mehrere Server nutzen, oft ohne dass es jemandem bewusst ist:

• DNS-01 von Hand: Der TXT-Eintrag wird einmal manuell gesetzt, danach werden über Wochen weitere Zertifikate für denselben Namen bezogen.
• Mehrere Server, ein Name: Knoten hinter einem Load Balancer bestellen je ein eigenes Zertifikat, validiert hat aber nur einer von ihnen.
• Zwei Schlüsseltypen: RSA- und ECDSA-Zertifikat werden getrennt bestellt, die zweite Bestellung stützt sich auf die Validierung der ersten.
• Getrennte Schritte in der Pipeline: Validiert wird beim Deploy, ausgestellt Tage später durch einen anderen Job.

Wie lange eine Autorisierung gilt, steht im Feld expires des Autorisierungsobjekts. In Staging lässt sich prüfen, ob jeder Server und jeder Schlüsseltyp seine Validierung selbst erbringt; wo der DNS-Eintrag noch von Hand gesetzt wird, ist jetzt der Zeitpunkt, das zu automatisieren.

Nach der Erneuerung: Reload, Verteilung, Kette

Let's Encrypt nennt die Umstellung eine Gelegenheit, Reload und Verteilung zu automatisieren und Alarme für gescheiterte Erneuerungen einzurichten. Für 2028 erwartet Let's Encrypt die Erneuerung um Tag 30 statt um Tag 60 und damit doppelt so viele Erneuerungsanfragen am Tag (Let's Encrypt). Jeder Handgriff nach der Erneuerung wird entsprechend öfter fällig, und dort liegt eine typische Lücke: Das neue Zertifikat liegt auf der Platte, ausgeliefert wird weiter das alte.

Ob die Erneuerung beim Besucher ankommt, zeigt nur ein Blick von außen. Der Vergleich ist einfach: Seriennummer und Ablaufdatum des Zertifikats, das der Server ausliefert, gegen die Datei, die der Client zuletzt geschrieben hat. In der folgenden Beispielausgabe liegt auf der Platte bereits das neue Zertifikat, ausgeliefert wird noch das alte, der Reload fehlt:

Monitoring auf die neue Laufzeit einstellen

Die Prüfung von außen übernimmt in XICTRAQ® das SSL-Monitoring als Teil des Uptime-Monitorings. Es prüft das ausgelieferte Zertifikat auf bezahlten Plänen alle sechs Stunden, im Free-Plan täglich, und führt einen Verlauf je Website. Ändert sich das Gültig-bis-Datum, verbucht der Verlauf eine Erneuerung, und der SSL-Tab zeigt die Gesamtlaufzeit des Zertifikats. So lässt sich ab Februar je Hostname ablesen, wann das erste 64-Tage-Zertifikat ausgeliefert wurde. Hostnamen mit eigenem Zertifikat, etwa app und api, werden dafür jeweils als eigene Website angelegt.

Für die Warnungen zählt die Vorwarnzeit. Sie gilt für alle Websites eines Kontos, ist auf 14 Tage voreingestellt und lässt sich unter Einstellungen, Benachrichtigungen zwischen 1 und 90 Tagen wählen. Unterschreitet die Restlaufzeit diese Schwelle, geht eine Warnung raus; jede weitere Stufe bei 7, 3 und 1 Tag meldet sich erneut, ab höchstens 3 Tagen als kritischer Alarm. Nach einer erfolgreichen Erneuerung löst sich der Alarm von selbst auf. Die Einzelheiten stehen im Handbuch zur SSL-Überwachung.

Die Vorgabe von 14 Tagen passt zu 64 Tagen, und das lässt sich nachrechnen. Wird bei zwei Dritteln erneuert, hat ein 64-Tage-Zertifikat zu diesem Zeitpunkt noch rund 21 Tage Restlaufzeit. Scheitert die Erneuerung, vergehen gut sieben Tage, bis die Warnung kommt, und danach bleiben 14 Tage zum Beheben. Wer die Vorwarnzeit für 90-Tage-Zertifikate auf 30 Tage hochgesetzt hat, bekommt ab Februar dagegen bei jedem 64-Tage-Zertifikat eine Warnung, bevor die Automatik überhaupt erneuern will. Das löst sich nach der Erneuerung auf, erzeugt aber in jedem Zyklus Meldungen ohne Anlass.

Alle Werte der Tabelle sind aus der Laufzeit gerechnet, nicht gemessen. Bei 45 Tagen schrumpft der Puffer auf einen Tag, und eine Erneuerung, die nur einen Wiederholungsversuch am Folgetag braucht, löst dann schon die Warnung aus. Spätestens 2028 lohnt es deshalb, die Vorwarnzeit auf etwa 10 Tage zu senken.

Die Zertifikatsprüfung sieht das Ergebnis, nicht den Lauf, und meldet sich im Beispiel erst gut eine Woche nach der verpassten Erneuerung. Früher meldet sich ein Heartbeat-Monitor am Erneuerungsjob: Das Skript ruft nach jedem erfolgreichen Lauf eine eigene Ping-Adresse auf, und bleibt der Aufruf über das erwartete Intervall hinaus aus, alarmiert XICTRAQ®. Bei zwei Läufen täglich passt ein Intervall von zwölf Stunden mit etwas Toleranz; mehr dazu im Beitrag zum Heartbeat-Monitoring für Cron-Jobs.

# /etc/cron.d/certificates
# Zweimal täglich zu einer krummen Minute, Ausgabe ins Log, Ping nur bei Erfolg
17 4,16 * * * root /usr/local/bin/renew-check.sh >>/var/log/cert-renew.log 2>&1 && curl -fsS -m 10 https://api.xictraq.com/api/heartbeat/<slug>/ping >/dev/null

Ein abgelaufenes Zertifikat trifft nicht zwingend die ganze Website. Läuft es nur auf einer Subdomain für Bilder, Skripte oder eine Schnittstelle ab, bleibt die Startseite erreichbar, aber Schaltflächen reagieren nicht mehr. In der Besucheranalyse zeigt sich das als Häufung von Rage- und Dead-Clicks; einen Kaufabschluss über alle beteiligten Hostnamen prüft dagegen ein Browser-Check, etwa beim Einlösen eines Rabattcodes im Checkout.

Der Prüfplan bis Februar 2027

Der Plan sollte bis zum 10. Februar 2027 erledigt sein; die Reihenfolge folgt dem Risiko: erst finden, was bricht, dann testen, dann überwachen.

• Bestand erfassen: jeder Hostname mit Zertifikat von Let's Encrypt, mit Client, Profil, Erneuerungsregel und Folgeschritten.
• Feste Tage suchen: Cron-Jobs, Skripte und Betriebshandbücher nach 83, 80 und 60 durchsuchen und jeden Treffer bewerten (Let's Encrypt).
• Regel umstellen: ARI aktivieren, wo der Client es kann, sonst auf zwei Drittel der Laufzeit.
• Staging-Test: einen Hostnamen gegen Staging erneuern, die Laufzeit von 64 Tagen und den nächsten Termin prüfen.
• Wiederverwendung prüfen: Abläufe finden, in denen eine Validierung für mehrere Server oder Schlüsseltypen herhalten muss.
• Folgeschritte automatisieren: Reload, Verteilung auf weitere Systeme und Alarm bei Fehlschlag.
• Monitoring anpassen: jeder Hostname als eigene Website, passende Vorwarnzeit, Heartbeat am Erneuerungsjob.
• Nach dem 10. Februar nachmessen: für jeden Hostnamen das erste 64-Tage-Zertifikat im Verlauf bestätigen und Ende März die erste Erneuerung im neuen Rhythmus abwarten.
• Bis zum 11. Mai abschließen: Dann ist nach Erwartung von Let's Encrypt jedes 90-Tage-Zertifikat ausgelaufen; ein nicht ersetztes im Verlauf zeigt eine Erneuerung, die nicht mehr läuft.

Erneuerung prüfen, bevor der Kalender es tut

Für eine gut automatisierte Umgebung ist die Umstellung auf 64 Tage ein Nicht-Ereignis, und genau das lässt sich jetzt in Staging belegen statt vermuten. Einen schnellen Einzelstand liefert der kostenlose SSL-Check; die fortlaufende Überwachung mit Verlauf, Warnstufen und Heartbeat für den Erneuerungsjob lässt sich nach der Registrierung einrichten.