Let's Encrypt so automatisieren, dass man nie wieder an Zertifikate denkt

Let's Encrypt-Zertifikate sind exakt 90 Tage gültig. Das ist so kurz, dass manuelle Verlängerungen unrealistisch sind. Automatisierung ist hier praktisch Pflicht. Die meisten Server, die ich übernehme, haben bereits einen certbot renew-Befehl irgendwo in einem Cronjob oder systemd-Timer versteckt (das Setup-Skript von Certbot erledigt das meist automatisch).

Das ist allerdings nur die halbe Miete. Was fast immer fehlt, ist das Gesamtbild: Sicherstellen, dass der Webserver das erneuerte Zertifikat überhaupt lädt, der korrekte Umgang mit Wildcard-Zertifikaten und ein Alerting-System, das lautlose Fehlschläge meldet, bevor das Zertifikat abläuft.

Der Reload-Schritt, den alle vergessen

Wenn Certbot ein Zertifikat erneuert, schreibt es die neuen Dateien unter /etc/letsencrypt/live/example.com/ auf die Platte. Es sagt jedoch Nginx, Postfix oder anderen involvierten Diensten nicht automatisch, dass sie die neuen Dateien auch verwenden sollen.

Die Lösung ist ein Deploy-Hook – ein Skript, das Certbot sofort nach einer erfolgreichen Verlängerung ausführt:

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

Wenn sich mehrere Dienste auf einem Server Zertifikate teilen, kann ein solches Skript alles auf einmal erledigen:

#!/bin/bash
# /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh
systemctl reload nginx
systemctl reload postfix
systemctl reload dovecot

Jedes Skript, das in /etc/letsencrypt/renewal-hooks/deploy/ abgelegt wird, läuft nach jeder erfolgreichen Zertifikatserneuerung völlig automatisch. Es ist ein einmaliges Setup und kein Post-it-Zettel, der einen alle 90 Tage auf dem Monitor angrinst.

Wildcard-Zertifikate brauchen DNS-01

Die Standard-HTTP-01-Challenge (bei der Certbot temporär eine Datei über Port 80 ausliefert) funktioniert für Wildcard-Zertifikate nicht. Wildcards erfordern zwingend die DNS-01-Challenge, die den Domainbesitz belegt, indem sie temporär einen TXT-Record anlegt. Bei DNS-Anbietern mit Certbot-Plugin lässt sich das vollständig automatisieren:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d example.com -d '*.example.com'

Die Datei mit den Zugangsdaten enthält einen API-Token, der strikt nur für DNS-Bearbeitungen berechtigt ist. Certbot legt den TXT-Record an, wartet auf die weltweite Propagation und löscht ihn nach erfolgreicher Validierung wieder – null manuelle Schritte. Richten Sie das ein, auch wenn Sie aktuell noch kein Wildcard-Zertifikat benötigen. Sobald ein Kunde ein Wildcard verlangt, ist die einzige Alternative eine händische DNS-01-Challenge alle 90 Tage. Und das ist genau die Art von wiederkehrender Fleißarbeit, die irgendwann vergessen wird.

Ausfälle bemerken, bevor es der Browser tut

Das wahre Risiko ist das stille Scheitern einer Erneuerung. Certbot kann wochenlang fehlschlagen, bevor ein Zertifikat abläuft. Da es die Verlängerung bei jedem Lauf erneut versucht, ist das erste Anzeichen für ein Problem ohne Monitoring eine bildschirmfüllende Browserwarnung auf der Live-Site.

Ein einfacher Bash-Check, der wöchentlich läuft, fängt dieses Risiko frühzeitig ab:

#!/bin/bash
# cert-expiry-check.sh
for domain in example.com mail.example.com; do
  expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 ))
  if [ "$days" -lt 14 ]; then
    echo "WARNUNG: Das Zertifikat von $domain läuft in $days Tagen ab"
  fi
done

Der Standard-Schwellenwert für Verlängerungen in Certbot liegt bei 30 Tagen vor Ablauf. Ein Zertifikat, das nur noch 14 Tage Restlaufzeit hat, ist eine gewaltige Red Flag dafür, dass Verlängerungsversuche seit Langem lautlos scheitern. Die Ursache ist so gut wie immer eine neue Firewall-Regel, die die HTTP-01-Challenge blockiert, ein abgelaufener DNS-API-Token für DNS-01 oder eine Domain, die umgeleitet wurde, ohne dass jemand Certbots Konfiguration angepasst hat.

Was "automatisiert" wirklich bedeutet

Ein Cronjob, der zwar existiert, aber keine Dienste neu lädt, keine Wildcards unterstützt und keine Fehler meldet, ist keine Automatisierung. Es ist ein extrem fragiler Prozess, bei dem nach wie vor indirekt ein Mensch involviert ist – man merkt es eben nur erst dann, wenn der Kunde wütend anruft.

Wahre Automatisierung bedeutet: Das Zertifikat wird erneuert, der Dienst lädt es automatisch, und man wird alarmiert, falls unterwegs etwas kaputtgeht – und das alles, ohne sich jemals einen 90-Tage-Zyklus merken zu müssen. Wenn das einmal sauber aufgesetzt ist, sind SSL-Zertifikate eines der ganz wenigen Dinge auf einem Server, die sich tatsächlich komplett allein um sich selbst kümmern.