Zertifikate werden kurzlebig: was das für deinen Server heißt

Die Laufzeit von TLS-Zertifikaten schrumpft. Let's Encrypt bietet seit Januar 2026 ein Profil mit sechs Tagen Gültigkeit (160 Stunden), die Sperrinformationen per OCSP sind seit 2025 aus den Zertifikaten verschwunden, und die Branche bewegt sich insgesamt auf kürzere Fristen zu.

Für einen Server mit funktionierender Automatisierung ändert das wenig. Für einen mit halber Automatisierung ändert es alles.

Stand 19.08.2026

Angaben zu Profilen und Fristen stammen von Let's Encrypt und aus der Berichterstattung. Fristen in diesem Feld werden regelmäßig nachgeschärft, vor einer Umstellung die aktuelle Ankündigung lesen, nicht diesen Beitrag. Das Vorgehen unten bleibt gleich.

Was sich geändert hat#

	Früher	Jetzt
Standardlaufzeit	90 Tage	90 Tage, plus optionales Profil mit 6 Tagen
Erneuerung sinnvoll ab	30 Tage Restlaufzeit	täglich prüfen, beim Kurzprofil zwingend
Sperrung per OCSP	im Zertifikat verlinkt	entfällt; Kurzzeit-Zertifikate haben weder OCSP noch CRL
Zertifikate auf IP-Adressen	nicht möglich	möglich (nur im Kurzprofil)

Die Logik dahinter: Ein Zertifikat, das nach sechs Tagen ohnehin ungültig ist, braucht keinen Sperrmechanismus. Die kurze Laufzeit ist die Sperre.

Was das praktisch verlangt#

1. Erneuerung muss automatisch laufen und zwar oft.

# certbot bringt seinen Timer mit. Läuft er?
systemctl list-timers | grep certbot
certbot renew --dry-run

Bei Caddy und Traefik passiert das ohne Zutun; bei certbot und acme.sh hängt es an einem Timer. Wie so ein Timer aussieht und warum er einem Cronjob vorzuziehen ist: systemd-Timer statt Cronjob.

2. Der Neustart danach muss auch klappen.

Der häufigste Fehler ist nicht die Erneuerung, sondern das, was danach fehlt: Das neue Zertifikat liegt auf der Platte, der Dienst benutzt noch das alte.

# certbot: Hook, der nach jeder Erneuerung läuft
cat > /etc/letsencrypt/renewal-hooks/deploy/neu-laden.sh <<'CFG'
#!/bin/sh
systemctl reload nginx
CFG
chmod +x /etc/letsencrypt/renewal-hooks/deploy/neu-laden.sh

# Gegenprobe: welches Zertifikat liefert der Server WIRKLICH aus?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject

Der zweite Befehl ist der ehrliche: Er fragt den laufenden Dienst, nicht das Dateisystem.

3. Überwachung, die zur Laufzeit passt.

Eine Warnung bei 14 Tagen Restlaufzeit wird nie ausgelöst

Bei sechs Tagen Gesamtlaufzeit schlägt ein Schwellwert von 14 Tagen dauerhaft Alarm, oder, je nach Aufbau, nie rechtzeitig. Die Überwachung muss auf die Laufzeit abgestimmt sein: bei 90 Tagen warnen ab 21, bei 6 Tagen warnen, wenn das Zertifikat älter als 3 Tage ist. Und wichtiger als die Restlaufzeit ist ohnehin: Wann lief die letzte Erneuerung erfolgreich?

# Restlaufzeit in Stunden, für die Überwachung
ende=$(echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ($(date -d "$ende" +%s) - $(date +%s)) / 3600 )) Stunden

Wie so eine Prüfung in die vorhandene Überwachung kommt, steht in Monitoring aufsetzen.

Soll ich auf das Kurzprofil umstellen?#

Nur mit einer ehrlichen Antwort auf drei Fragen:

Läuft die Erneuerung ohne Zutun, mehrmals täglich geprüft?
Lädt der Dienst danach nachweislich neu, geprüft am ausgelieferten Zertifikat, nicht an der Datei?
Merkt jemand innerhalb von Stunden, wenn beides scheitert?

Dreimal ja: Das Kurzprofil ist ein Sicherheitsgewinn, weil ein abhandengekommener Schlüssel nach Tagen wertlos ist. Einmal nein: Bleib bei 90 Tagen und repariere zuerst die Automatisierung, ein abgelaufenes Zertifikat ist ein Totalausfall, kein Schönheitsfehler.

# Umstellen bei certbot (Profilname laut aktueller Ankündigung)
certbot renew --cert-name example.com --preferred-profile shortlived --dry-run

Wer davon härter getroffen wird#

Alles mit Zertifikat außerhalb des Webservers: Mailserver, Datenbanken mit TLS, VPN-Endpunkte, Panels. Dort gibt es oft keinen automatischen Neustart nach der Erneuerung (eigener Mailserver).
Geräte, die Zertifikate von Hand bekommen, Router, Drucker, Kameras, alte Appliances.
Aufbauten mit Zertifikatspinning in Apps: Wenn eine App auf ein bestimmtes Zertifikat festgelegt ist, bricht bei jeder Erneuerung die Verbindung. Gepinnt wird der öffentliche Schlüssel, nicht das Zertifikat, sonst wird das mit kurzen Laufzeiten unhaltbar.
Manuelle Ausstellung per DNS-Prüfung ohne API des DNS-Anbieters. Bei sechs Tagen ist Handarbeit ausgeschlossen.

Häufige Fragen#

Muss ich jetzt etwas tun?#

Wenn deine Erneuerung automatisch läuft und der Dienst danach neu lädt: nein. Prüfen lohnt sich trotzdem, die zwei Befehle oben dauern eine Minute.

Was ist mit dem Wegfall von OCSP?#

Für Betreiber ändert sich wenig; OCSP-Stapling in der Serverkonfiguration läuft bei Zertifikaten ohne OCSP-URL einfach ins Leere. Wer es konfiguriert hat, kann die Zeilen entfernen, sie schaden nicht, tun aber nichts mehr.

Werden 90 Tage abgeschafft?#

Danach sieht es derzeit nicht aus; das Kurzprofil ist eine zusätzliche Wahl. Der allgemeine Trend geht aber zu kürzeren Laufzeiten, also ist eine Automatisierung, die 90 Tage voraussetzt, mittelfristig eine Altlast.

Wie teste ich, ohne die Ausstellungsgrenze zu verbrennen?#

Mit dem Testserver der Zertifizierungsstelle (--dry-run bei certbot, caserver=…acme-staging… bei Traefik). Das gilt besonders beim Ausprobieren, siehe Traefik im Container-Netz.

Und Zertifikate auf IP-Adressen?#

Möglich, aber nur mit kurzer Laufzeit und praktisch relevant nur, wenn ein Dienst ohne Domainnamen erreichbar sein muss. Für die meisten Aufbauten ist der Domainname der bessere Weg.

Kurz gesagt#

Sechs-Tage-Zertifikate sind seit Januar 2026 verfügbar, OCSP ist raus.
Umstellen erst, wenn Erneuerung und Neustart und Überwachung nachweislich sitzen.
Am ausgelieferten Zertifikat prüfen (openssl s_client), nicht an der Datei.
Schwellwerte in der Überwachung an die Laufzeit anpassen, sonst warnen sie nie oder immer.
Am härtesten trifft es alles, was kein Webserver ist: Mail, VPN, Panels, Geräte.