Die Verlängerung von Let’s-Encrypt-Zertifikaten sollte im Alltag unspektakulär bleiben: einmal korrekt eingerichtet, läuft sie im Hintergrund und fällt nur auf, wenn etwas nicht stimmt. Genau darum geht es hier: wie der Certbot-Renew-Befehl arbeitet, wann du ihn manuell anstößt, wie du einen Testlauf sauber prüfst und welche Fehler in der Praxis Zeit kosten. Ich halte das bewusst anwendungsnah, weil bei SSL - technisch meist TLS - nicht die Theorie hilft, sondern ein Ablauf, der auf dem Server verlässlich funktioniert.
Die sichere Verlängerung hängt an drei Dingen: korrekter Konfiguration, sauberem Testlauf und einem funktionierenden Automatik-Job
- Certbot erneuert nur Zertifikate, die nah am Ablauf sind, und übernimmt dabei die zuletzt genutzten Optionen.
- Die Automatik läuft bei den meisten Installationen bereits über Cron oder systemd im Hintergrund.
- Ein Testlauf mit
--dry-runist der beste erste Schritt, bevor du eine echte Verlängerung anstößt. - Manuelle Zertifikate ohne Hooks erneuern sich nicht von selbst und brauchen einen anderen Ablauf.
- Wenn die Verlängerung scheitert, liegt die Ursache oft bei Port 80, Hooks, DNS-Zugang oder einem geänderten Webroot.
Was der Befehl bei der Erneuerung wirklich macht
Der Kern ist einfach: Certbot prüft alle verwalteten Zertifikate und versucht nur die zu verlängern, die aus seiner Sicht bald ablaufen. Seit Certbot 4.0.0 gilt dafür im Regelfall: Erneuert wird erst dann, wenn weniger als ein Drittel der Laufzeit übrig ist. Bei den üblichen 90-Tage-Zertifikaten entspricht das ungefähr den letzten 30 Tagen. Dadurch kannst du den Prozess regelmäßig laufen lassen, ohne dass ständig neue Zertifikate ausgestellt werden.
Wichtiger noch: Certbot nimmt für die Verlängerung normalerweise dieselben Plugins und Optionen wie beim ursprünglichen Ausstellen. Das ist praktisch, weil du die Erneuerung nicht bei jedem Durchlauf neu konfigurieren musst. Genau deshalb ist der Unterbefehl für die Verlängerung für Automatisierung gedacht und nicht für einen einmaligen Sonderfall.
Ich achte in der Praxis auf einen Punkt besonders: Ein nicht nötiger Lauf ist kein Fehler. Wenn gerade kein Zertifikat erneuert werden muss, beendet sich der Befehl trotzdem erfolgreich. Für Skripte ist das wichtig, weil ein sauberer Lauf nicht automatisch bedeutet, dass tatsächlich ein neues Zertifikat ausgestellt wurde.
Wenn du dieses Verhalten im Hinterkopf behältst, ist die nächste Frage naheliegend: Reicht die eingebaute Automatik schon aus oder musst du selbst eingreifen?
Wann die Automatik reicht und wann du manuell eingreifen musst
Die meisten Installationen bringen bereits einen geplanten Job mit, der die Erneuerung regelmäßig anstößt. Ich prüfe das zuerst, bevor ich überhaupt etwas ändere, weil doppelte Automatisierung unnötig verwirrend sein kann. Unter Linux suchst du typischerweise entweder in crontab oder bei systemd-Timern nach einem vorhandenen Job; unter Windows ist das laut Certbot bereits vorinstalliert.
| Situation | Was ich mache | Warum |
|---|---|---|
| Standard-Setup mit Apache, Nginx oder Webroot | Automatik laufen lassen und nur per Testlauf prüfen | Der Timer erledigt die Routine zuverlässig, ohne dass du eingreifen musst |
| DNS-Validierung mit API-Anbindung | Automatisch verlängern lassen | Auch Wildcard-Zertifikate können so ohne manuelle Schritte erneuert werden |
--manual ohne Auth-Hooks |
Mit einem manuellen Prozess arbeiten | Ohne Hook-Skripte lässt sich dieser Weg nicht sauber automatisieren |
| Webroot-Pfad oder Server-Layout geändert | Erneuerungskonfiguration prüfen und Testlauf wiederholen | Certbot muss die neue Realität auf dem Server kennen, sonst scheitert die Validierung |
| Webserver muss für die Validierung kurz stoppen | Pre- und Post-Hooks verwenden | So wird der Dienst sauber angehalten und nachher wieder gestartet |
Die Faustregel ist simpel: Wenn sich am Weg zur Domainvalidierung nichts geändert hat, brauchst du meist nur Kontrolle, nicht Umbau. Wenn sich aber Webroot, DNS-Zugang oder Reverse-Proxy-Setup geändert haben, musst du den Erneuerungsweg bewusst nachziehen. Genau dort entstehen die meisten unnötigen Ausfälle.
Damit ist die Automatik eingeordnet. Jetzt geht es darum, wie du eine Verlängerung testest, ohne direkt am Live-Zertifikat herumzuschieben.
So prüfst du eine Erneuerung ohne Risiko
Der sicherste erste Schritt ist ein Testlauf gegen die Staging-Umgebung. Dabei simuliert Certbot die Erneuerung, ohne ein echtes Produktionszertifikat zu überschreiben. Für mich ist das der Punkt, an dem man am meisten Zeit spart, weil man Fehler vor dem Ablaufdatum findet statt während eines Ausfalls.
sudo certbot renew --dry-runWenn dieser Test sauber durchläuft, ist das ein gutes Zeichen: Plugin, Challenge-Mechanismus, Webserver-Zugriff und Hooks greifen grundsätzlich zusammen. Scheitert der Test, schaue ich zuerst auf die Validierung selbst. Bei HTTP-Validierung muss Port 80 erreichbar sein, und bei Webroot-Lösungen muss der Server Dateien aus /.well-known/acme-challenge wirklich ausliefern.
Ich prüfe außerdem, ob zusätzliche Hooks sinnvoll sind. Wenn dein Webserver für die Erneuerung kurz stoppen muss, gehören Start und Stopp in Pre- und Post-Hooks. Soll nur nach erfolgreicher Erneuerung etwas passieren, ist ein Deploy-Hook die sauberere Wahl. Das ist die Art Detail, die später den Betrieb ruhig hält.
Wenn der Testlauf scheitert, heißt das noch nicht, dass das Zertifikat selbst kaputt ist. Meist liegt das Problem in der Umgebung rundherum. Genau dort setze ich als Nächstes an.
Die häufigsten Störungen in der Praxis
In echten Umgebungen sind die Ursachen meist erstaunlich banal. Die drei Klassiker sind ein geändertes Webroot, blockierte Erreichbarkeit auf Port 80 und ein Zertifikat, das ursprünglich über --manual erzeugt wurde. Besonders bei manuellen Zertifikaten unterschätzen viele, dass ohne zusätzliche Hook-Logik keine echte Automatik möglich ist.
- Port 80 ist blockiert: Dann scheitert die HTTP-Validierung, auch wenn HTTPS selbst schon sauber läuft.
- Der Webroot-Pfad ist nicht mehr aktuell: Nach Umzug, Containerwechsel oder Deployment-Umstellung zeigt Certbot auf das falsche Verzeichnis.
- DNS-Zugang fehlt oder Credentials sind falsch: Das betrifft vor allem DNS-Challenges und Wildcard-Zertifikate.
- Hooks schlagen fehl: Ein ausgefallenes Restart- oder Reload-Skript kann die Erneuerung indirekt scheitern lassen.
- Es wurde auf die Zertifikatsdateien kopiert statt auf die Live-Pfade verwiesen: Dann sieht der Webserver nach der Erneuerung weiter alte Dateien.
-
Zu häufig erzwungene Erneuerungen: Mit
--force-renewalkann man sich schnell in Rate-Limits der CA manövrieren.
Ein Punkt wird dabei oft übersehen: Die Rückmeldung des Befehls ist nicht gleichbedeutend mit „Zertifikat wurde erneuert“. Ein erfolgreicher Lauf kann auch einfach heißen, dass gerade nichts zu tun war. Wenn du also Automatisierung baust, solltest du auf den tatsächlichen Erneuerungsfall und nicht nur auf den Rückgabecode schauen.
Wenn ich tiefer bohre, lande ich fast immer in /var/log/letsencrypt/letsencrypt.log. Dort sehe ich meist schnell, ob das Problem bei der Challenge, beim Hook oder beim Pfad lag.
Wenn die Fehlerquellen bekannt sind, lässt sich der Betrieb deutlich robuster aufsetzen. Genau darauf kommt es im Alltag an.
So läuft die Erneuerung im Alltag stabil
Ich halte Zertifikate am liebsten so, dass der Erneuerungsprozess fast langweilig wird. Das klingt unspektakulär, ist aber das beste Kompliment für Infrastruktur. Drei Dinge machen den Unterschied: regelmäßige Läufe, saubere Hooks und keine unnötigen Sonderwege.
- Regelmäßig testen: Ein Testlauf gehört vor Änderungen an Webroot, Proxy oder DNS genauso dazu wie nach der Erstinstallation.
- Deploy-Hooks nutzen: Wenn ein Dienst nach der Erneuerung neu laden muss, gehört das in einen expliziten Hook und nicht in ein manuelles Nacharbeiten.
-
Auf die Live-Pfade zeigen: Webserver-Konfigurationen sollten direkt auf
/etc/letsencrypt/live/...verweisen, nicht auf kopierte Dateien. -
Konfiguration nicht leichtfertig anfassen: Die Renewal-Dateien unter
/etc/letsencrypt/renewal/sind empfindlich; Änderungen dort mache ich nur mit Backup und Testlauf. - Verantwortung klar trennen: Certbot erneuert das Zertifikat, der Webserver lädt es danach neu.
Für einen schnellen Statuscheck nutze ich zusätzlich certbot certificates; damit sehe ich Laufzeiten und Zertifikatsnamen auf einen Blick. Wenn ich einen Betrieb sauber abnehme, prüfe ich am Ende immer noch einmal die Zertifikatsübersicht und die Restlaufzeit. So sehe ich, ob die Automatisierung wirklich greift und ob alle Namen korrekt abgedeckt sind. Das ist die Art Kontrolle, die man nicht täglich braucht, aber sehr schätzt, wenn ein Zertifikat plötzlich in den letzten Tagen vor Ablauf hängt.
Was bei einem sauberen Zertifikatsbetrieb wirklich den Unterschied macht
Am Ende ist die Erneuerung kein Sonderthema, sondern ein kleiner, aber kritischer Teil des Betriebs. Wer den Ablauf einmal verständlich aufsetzt, spart sich später die hektischen Minuten vor dem Ablaufdatum. Für mich ist die Reihenfolge klar: erst prüfen, dann automatisieren, dann nur noch auf Ausnahmen reagieren.
Wenn du aus diesem Artikel nur drei Dinge mitnimmst, dann diese: Erneuerungen ruhig regelmäßig testen, manuelle Zertifikate nicht mit automatischen verwechseln und Änderungen an Webroot, DNS oder Hooks immer mit einem Testlauf absichern. Genau so bleibt TLS im Alltag unspektakulär, und das ist in der Infrastruktur meist das beste Ergebnis.
Praktisch heißt das: Solange deine Validierung noch zum Setup passt, läuft die Verlängerung fast von selbst. Sobald du aber Serverpfade, Provider oder Startskripte änderst, solltest du den nächsten Lauf bewusst überprüfen, statt auf Glück zu setzen.
