TLS-Zertifikate: kürzere Laufzeiten kommen, Handarbeit hört auf

Die maximal zulässige Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate sinkt in Stufen. Das CA/Browser-Forum hat 2025 beschlossen, sie schrittweise zu verkürzen, von 398 Tagen über 200 und 100 Tage bis auf 47 Tage im Jahr 2029. Wer heute noch von Hand erneuert, tut das künftig alle paar Wochen.

Der Stand, kurz#

Die Stichtage stammen aus dem Beschluss des CA/Browser-Forums (SC-081). Vor der Planung am aktuellen Stand prüfen, Termine solcher Beschlüsse werden gelegentlich verschoben, und diese Seite ist keine Primärquelle.

Einrichtung, die auch in fünf Jahren noch läuft#

# Debian/Ubuntu, Zertifikat für nginx
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.org -d www.example.org

# Was ist eingerichtet, und wann läuft der nächste Versuch?
sudo certbot certificates
systemctl list-timers certbot.timer --all

Zwei Details, die den Unterschied zwischen „läuft“ und „lief mal“ ausmachen:

# 1. Erneuerung einmal trocken durchspielen — jetzt, nicht in 40 Tagen
sudo certbot renew --dry-run

# 2. Dienst muss das neue Zertifikat auch laden
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload.sh >/dev/null <<'SH'
#!/bin/sh
systemctl reload nginx
SH
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload.sh

Punkt 2 ist der häufigste stille Fehler: Die Datei ist erneuert, der Prozess hält aber weiter das alte Zertifikat im Speicher, bis zum nächsten Neustart, der zufällig nach dem Ablaufdatum liegt.

Überwachen statt hoffen#

Automatisierung ohne Kontrolle verschiebt das Problem nur. Zwei Zeilen, die den Ablauf von außen messen:

# Restlaufzeit in Tagen, von einer anderen Maschine aus
ENDE=$(echo | openssl s_client -connect example.org:443 -servername example.org 2>/dev/null \
       | openssl x509 -noout -enddate | cut -d= -f2)
echo "$(( ( $(date -d "$ENDE" +%s) - $(date +%s) ) / 86400 )) Tage"

# Ganze Kette und Protokollversionen prüfen
openssl s_client -connect example.org:443 -servername example.org -showcerts </dev/null 2>/dev/null | head -20

Diese Prüfung gehört in dieselbe Überwachung wie alles andere, mit einem Schwellwert, der früh genug greift (bei 47-Tage-Zertifikaten reichen 30 Tage Vorwarnzeit nicht mehr, 10 sind realistischer). Wie ein Alarm aussieht, der auch nachts ankommt, steht in Alarme, die nachts ankommen.

Was außer dem Ablauf noch zählt#

• Nur aktuelle Protokollversionen: TLS 1.2 und 1.3, alles darunter aus.
• Kette vollständig ausliefern, fehlende Zwischenzertifikate fallen im Browser oft nicht auf, brechen aber API-Aufrufe.
• HSTS bewusst setzen, nicht kopieren: Der Header wirkt lange nach, auch wenn man es sich anders überlegt.
• Interne Dienste nicht vergessen. Für Verwaltungsoberflächen im internen Netz ist eine eigene kleine CA oft praktischer als öffentliche Zertifikate und sie unterliegt diesen Fristen nicht.

Ein sauber automatisiertes Zertifikat ist außerdem eine der wenigen technischen Maßnahmen, die sich gegenüber Kunden ohne Aufwand belegen lassen: Technische Maßnahmen belegen.