Let's Encrypt stellt Zertifikate für neunzig Tage aus und verlängert sie automatisch, weshalb man eine Woche nach der Einrichtung aufhört, an sie zu denken. Das Problem ist, dass die automatische Verlängerung still scheitert: Die Fehler sieht niemand, und drei Monate später empfängt die Website ihre Besucher mit einer Browserwarnung. Seit 2025 verschickt Let's Encrypt zudem keine Ablaufbenachrichtigungen mehr — die letzte äußere Erinnerung ist damit ebenfalls weg.

Nachfolgend die Gründe, aus denen die Verlängerung aufhört zu funktionieren, nach abnehmender Häufigkeit.

1. Das Zertifikat wurde verlängert, der Dienst hat es nie neu eingelesen

Der häufigste Fall. certbot renew lief durch, die neue Datei liegt auf der Platte, und nginx oder Apache behalten die alte im Speicher — und liefern sie den Besuchern aus, bis die Konfiguration neu geladen wird. Formal ist alles in Ordnung, tatsächlich hat die Website ein abgelaufenes Zertifikat.

Abhilfe schafft ein Hook, der nach erfolgreicher Verlängerung ausgeführt wird:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Das wird einmal in die Verlängerungsdatei geschrieben (/etc/letsencrypt/renewal/example.com.conf, Abschnitt [renewalparams], Zeile renew_hook) und arbeitet fortan von selbst.

2. Der Webserver hat sich geändert, die Prüfung nicht

Die HTTP-01-Prüfung verlangt, dass eine Datei aus /.well-known/acme-challenge/ über einfaches HTTP ausgeliefert wird. Kaputt geht das üblicherweise so:

  • Der Konfiguration wurde eine bedingungslose Umleitung von HTTP auf HTTPS hinzugefügt — die Prüfung landet in der Umleitung und scheitert;
  • Es kam eine Regel location ~ /\. mit deny all hinzu, die alle Verzeichnisse mit Punkt schließt, .well-known eingeschlossen;
  • Das Wurzelverzeichnis der Website ist umgezogen, während in den certbot-Einstellungen der alte --webroot-path steht;
  • Eine Ländersperre oder eine Basic-Authentifizierung wurde aktiviert und hat den Prüfserver gleich mit erfasst.

Die richtige Reihenfolge in der Konfiguration: zuerst ein eigener location-Block für /.well-known/acme-challenge/, erst danach die allgemeine Umleitung.

3. Der Timer ist aus

Die Verlängerung startet über einen systemd-Timer oder einen Cron-Auftrag, und beides lässt sich beim Debuggen versehentlich abschalten oder beim Serverumzug verlieren.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

Der zweite Befehl führt einen vollständigen Verlängerungszyklus im Testmodus aus, ohne Ihr Kontingent zu verbrauchen. Er ist die einzige Prüfung, die „wird das in einem Monat verlängert“ im Voraus beantwortet statt hinterher.

4. Eine Domain zeigt nicht mehr hierher

Das Zertifikat umfasst fünf Domains, eine davon ist auf einen anderen Hoster umgezogen, das DNS wurde geändert. Die Prüfung dieser Domain schlägt fehl, und certbot verlängert das gesamte Zertifikat nicht — die vier funktionierenden Domains eingeschlossen. Überzählige Domains müssen aus dem Zertifikat entfernt werden, nicht samt Meldung ignoriert.

5. Sie sind an die Limits gestoßen

Let's Encrypt begrenzt die Zahl der Zertifikate je Domain und Woche. Das ist normalerweise die Folge einer „hat nicht geklappt, probiere es nochmal“-Schleife beim Debuggen. Für Experimente gibt es einen Testserver (--dry-run oder --test-cert), und den sollte man nutzen, bevor das Limit erschöpft ist, nicht danach.

Prüfen Sie, was ausgeliefert wird, nicht was gespeichert ist

Jede dateibasierte Prüfung hat denselben Mangel: Die Datei kann frisch sein, während der Besucher das alte Zertifikat erhält. Sehen Sie aus Sicht des Clients nach:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Die Option -servername ist zwingend: Ohne sie erhalten Sie auf einem Server mit mehreren Websites das Zertifikat des erstbesten virtuellen Hosts und nicht das gemeinte. In der Ausgabe ist notAfter das echte Ablaufdatum.

Prüfen Sie bei der Gelegenheit die Kette:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Ist nur ein Zertifikat vorhanden, wird das Zwischenzertifikat nicht ausgeliefert. Browser verzeihen das meist — sie bauen die Kette selbst zusammen —, aber curl, mobile Anwendungen und Java-Clients scheitern an der Prüfung. Das ist der Klassiker „bei mir geht alles auf, beim Kunden nicht“.

Wie viele Tage Vorwarnung

Dreißig Tage sind eine vernünftige erste Warnung: So viel bleibt auch, wenn certbot mit den Verlängerungsversuchen beginnt — ist bis dahin nichts geschehen, ist der Mechanismus defekt. Vierzehn Tage sind die zweite Warnung, die schon heute Handeln verlangt. Sieben sind ein Notfall.

Wichtig ist, alle Zertifikate zugleich im Blick zu haben, auch die nicht von Let's Encrypt stammenden: Die für ein Jahr gekauften werden am zuverlässigsten vergessen, weil in einem Jahr alle sowohl sie als auch die Frage vergessen haben, in wessen Postfach die Benachrichtigungen laufen. Eine Seite mit Domains, Daten und Resttagen schließt das Thema vollständig ab — wie in der Demo unten.