Blog

TLS-Zertifikate bald nur noch 40 Tage gültig: Was das bedeutet und wie man sich vorbereitet

9. Juni 2026 · 14 min Lesezeit
Auf Play klicken um den Artikel vorlesen zu lassen.
TLSZertifikateLet's EncryptACMECertbotCA/Browser ForumSicherheit TLS Zertifikate Let's Encrypt ACME Certbot CA/Browser Forum Sicherheit

Lange Zeit war ein TLS-Zertifikat etwas, das man einmal im Jahr erneuerte — oder vergaß, bis der Browser die rote Warnung zeigte. Diese Ära geht zu Ende. Das CA/Browser Forum, das Gremium aus Zertifizierungsstellen und Browser-Herstellern, das die Standards für TLS-Zertifikate definiert, hat eine tiefgreifende Änderung beschlossen: Die maximale Gültigkeitsdauer von TLS-Zertifikaten wird schrittweise drastisch verkürzt — auf langfristig 40 Tage.

Für viele Administratoren klingt das zunächst nach einem bürokratischen Alptraum. In der Praxis ist es das Gegenteil: ein notwendiger Schritt, der die Zertifikatsverwaltung endlich zwingt, das zu werden, was sie schon lange sein sollte — vollständig automatisiert.

Der aktuelle Stand: 398 Tage und ihre Geschichte

Wer ein TLS-Zertifikat bei einer kommerziellen CA (Certificate Authority) kauft, bekommt aktuell maximal 398 Tage Laufzeit. Diese Grenze ist nicht zufällig: Sie entspricht 13 Monaten und wurde 2020 durchgesetzt — hauptsächlich auf Druck von Apple, das ankündigte, Zertifikate mit längerer Laufzeit in Safari schlicht nicht mehr zu akzeptieren.

Vor 2020 waren zwei Jahre (825 Tage) der Standard, davor sogar fünf Jahre. Die Logik hinter immer kürzeren Laufzeiten ist einfach: Ein Zertifikat, das kompromittiert wurde, muss irgendwann ungültig werden. Je kürzer die Laufzeit, desto kleiner das Zeitfenster, in dem ein Angreifer ein gestohlenes oder gefälschtes Zertifikat missbrauchen kann.

Was das CA/Browser Forum beschlossen hat

Der Beschluss — bekannt als Ballot SC-081 bzw. dessen Nachfolger — sieht eine stufenweise Verkürzung vor. Die genauen Daten variieren je nach Fassung, aber das Grundprinzip ist festgelegt:

  • Ab 2026: Maximale Laufzeit 200 Tage
  • Ab 2027: Maximale Laufzeit 100 Tage
  • Ab 2029 (Langfristziel): Maximale Laufzeit 40–47 Tage

Gleichzeitig wird die maximal zulässige Wiederverwendung von Domain-Validierungsdaten (das sogenannte Domain Control Validation Reuse Period) entsprechend verkürzt. Bisher konnten CAs eine einmal durchgeführte Domain-Validierung bis zu 398 Tage lang wiederverwenden, um neue Zertifikate auszustellen. Auch das wird auf 10 Tage reduziert — was bedeutet: Bei jeder Zertifikatsausstellung muss die Domain-Kontrolle frisch nachgewiesen werden.

Warum 40 Tage? Die technischen Argumente

Schnellere Reaktion auf Kompromittierungen

Das fundamentale Problem mit Zertifikaten ist: Revokation funktioniert in der Praxis kaum. CRLs (Certificate Revocation Lists) werden selten abgerufen, OCSP-Stapling ist nicht überall implementiert, und Browser-Hersteller haben sich aus Performance-Gründen weitgehend von Hard-Fail-Revokation verabschiedet. Ein kompromittiertes Zertifikat mit 13 Monaten Laufzeit ist in der Praxis also faktisch 13 Monate lang nutzbar — auch wenn es revoziert wurde. Mit 40 Tagen Laufzeit hat ein Angreifer maximal 40 Tage.

Agilität bei Algorithmuswechseln

Stell dir vor, morgen wird ein kritischer Schwachstellen in RSA-2048 entdeckt. Wie lange dauert es, alle ausgestellten Zertifikate abzulösen? Bei 398 Tagen Laufzeit: bis zu 398 Tage. Bei 40 Tagen: maximal 40 Tage. Kürzere Lebenszyklen ermöglichen eine schnellere Ablösung veralteter kryptographischer Algorithmen — ein zunehmend wichtiger Faktor angesichts des Fortschritts bei Quantencomputern und der langfristig anstehenden Migration zu post-quanten-sicheren Verfahren.

Reduktion von Zombie-Zertifikaten

In der Praxis gibt es zahlreiche Zertifikate, die für Domains ausgestellt wurden, die längst nicht mehr unter der Kontrolle ihrer ursprünglichen Eigentümer stehen — wegen Domainverfalls, Unternehmensübernahmen oder einfach vergessener Subdomains. Kurze Laufzeiten sorgen dafür, dass solche Zertifikate schnell auslaufen, statt jahrelang ein Sicherheitsrisiko darzustellen.

Erzwungene Automatisierung

Das ist das vielleicht wirkungsvollste Argument: Wenn Zertifikate alle 40 Tage erneuert werden müssen, ist manuelles Management schlicht nicht mehr praktikabel. Wer zehn Domains betreibt, muss alle drei bis vier Wochen Zertifikate erneuern — manuell ist das ein Vollzeitjob. Die Verkürzung erzwingt Automatisierung, was seinerseits die Fehlerrate massiv senkt. Manuell vergessene Zertifikatserneuerungen — der häufigste Grund für TLS-Ausfälle — entfallen schlicht.

Let's Encrypt als Vorbild

Let's Encrypt hat die Industrie bereits seit seiner Gründung 2015 in diese Richtung getrieben. Die kostenlosen Zertifikate haben von Anfang an eine Laufzeit von nur 90 Tagen — bewusst kurz, um Automatisierung zum Standard zu machen. Der ACME-Protokoll-Standard (Automatic Certificate Management Environment, RFC 8555) ist das Ergebnis dieser Philosophie: eine standardisierte API, über die Zertifikate vollautomatisch beantragt, validiert und erneuert werden können.

Heute nutzen Millionen von Servern Let's Encrypt mit Certbot oder alternativen ACME-Clients. Die 90-Tage-Laufzeit ist für die meisten kein Problem mehr — weil die Erneuerung schlicht automatisiert ist. 40 Tage sind der logische nächste Schritt. Let's Encrypt hat bereits angekündigt, in Zukunft auch 6-Tage-Zertifikate anbieten zu wollen — für maximale Agilität.

Was das konkret für dich bedeutet: Handlungsbedarf nach Situation

Szenario 1: Du nutzt bereits Let's Encrypt mit Certbot

Herzlichen Glückwunsch — du bist bereits gut aufgestellt. Certbot richtet bei der Installation einen Cron-Job oder systemd-Timer ein, der zweimal täglich prüft, ob eine Erneuerung nötig ist (standardmäßig bei unter 30 Tagen Restlaufzeit). Für 40-Tage-Zertifikate musst du diesen Schwellwert anpassen:

# /etc/letsencrypt/cli.ini oder certbot renew --renew-before-expiry
renew_before_expiry = 20 days

Prüfe außerdem, ob der Timer aktiv ist:

systemctl status certbot.timer
# oder
crontab -l | grep certbot

Szenario 2: Du nutzt Let's Encrypt mit acme.sh

acme.sh ist eine populäre Alternative zu Certbot, die als reines Shell-Skript ohne externe Abhängigkeiten läuft. Auch hier wird ein Cron-Job installiert. Der Erneuerungsschwellwert lässt sich global setzen:

# In ~/.acme.sh/account.conf
RENEW_DAYS="20"

Oder pro Zertifikat beim Ausstellen:

acme.sh --issue -d example.com --renew-days 20

Szenario 3: Du nutzt kommerzielle Zertifikate manuell

Das ist das größte Problem. Wer bisher ein Wildcard-Zertifikat gekauft, manuell in den Webserver eingebunden und einmal jährlich erneuert hat, muss umdenken. Optionen:

  1. Migration zu Let's Encrypt: Für die meisten Szenarien die beste Wahl. Kostenlos, automatisierbar, weitgehend universell akzeptiert. Wildcard-Zertifikate sind über DNS-01-Challenge möglich.
  2. ACME-API des kommerziellen Anbieters nutzen: Viele CAs bieten inzwischen ACME-Endpunkte an. DigiCert, Sectigo, GlobalSign — alle haben ACME-Schnittstellen. Certbot oder acme.sh können damit genauso genutzt werden wie mit Let's Encrypt.
  3. Automatisierung im Webserver: Caddy hat ACME-Support nativ eingebaut und erneuert Zertifikate vollautomatisch ohne Konfiguration. Bei Nginx oder Apache kann traefik als Reverse-Proxy vor den eigentlichen Server geschaltet werden und die Zertifikatsverwaltung übernehmen.

Szenario 4: Enterprise-Umgebungen mit interner PKI

Viele Unternehmen betreiben eigene Certificate Authorities für interne Dienste. Die CA/B-Forum-Änderungen betreffen primär öffentlich vertrauenswürdige Zertifikate — interne CAs können weiterhin längere Laufzeiten ausstellen. Trotzdem empfiehlt sich eine Überprüfung der internen Prozesse: Wenn öffentliche Zertifikate jetzt automatisiert erneuert werden müssen, ist das ein guter Moment, dasselbe für interne Zertifikate zu implementieren.

EJBCA, HashiCorp Vault PKI, oder Microsoft ADCS bieten alle ACME-Schnittstellen oder vergleichbare APIs für automatisiertes Zertifikatsmanagement.

Wildcard-Zertifikate: Die Sonderrolle

Wildcard-Zertifikate (*.example.com) sind über Let's Encrypt mittels DNS-01-Challenge möglich, erfordern aber API-Zugang zum DNS-Provider. Das funktioniert hervorragend mit verbreiteten Anbietern (Cloudflare, Hetzner DNS, INWX), erfordert aber API-Schlüssel mit Schreibzugriff auf DNS-Einträge — ein Sicherheitsrisiko, das bedacht werden muss.

Für Cloudflare:

# certbot mit Cloudflare-Plugin
pip install certbot-dns-cloudflare
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d "*.example.com" -d "example.com"

Die cloudflare.ini enthält nur den API-Token mit minimalen Berechtigungen (Zone:DNS:Edit für die betroffene Domain).

Monitoring: Ablaufende Zertifikate nie wieder vergessen

Auch bei vollständiger Automatisierung ist Monitoring sinnvoll — für den Fall, dass ein Renewal-Job fehlschlägt. Einfache Lösung mit OpenSSL:

#!/bin/bash
# check-cert.sh — Zertifikat-Ablauf prüfen
DOMAIN=$1
DAYS_WARN=14
EXPIRY=$(echo | openssl s_client -connect ${DOMAIN}:443 -servername ${DOMAIN} 2>/dev/null \
  | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "${EXPIRY}" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
echo "${DOMAIN}: ${DAYS_LEFT} Tage verbleibend (läuft ab: ${EXPIRY})"
[ $DAYS_LEFT -lt $DAYS_WARN ] && echo "WARNUNG: Zertifikat läuft bald ab!"

Für Umgebungen mit vielen Domains empfehlen sich dedizierte Monitoring-Lösungen: Zabbix hat einen eingebauten TLS-Zertifikats-Check, Prometheus mit dem blackbox_exporter überwacht Zertifikate und kann Alerting über Alertmanager einrichten, und Uptime Kuma bietet als self-hosted Alternative einfaches Zertifikats-Monitoring mit Benachrichtigungen per E-Mail, Telegram oder ähnlichem.

Wann muss man handeln?

Die Übergangszeiträume sind bewusst lang gewählt — niemand muss sofort auf 40-Tage-Zertifikate umstellen. Aber die Richtung ist klar, und frühzeitiges Handeln vermeidet späteren Stress:

  • Sofort: Inventar aufnehmen. Welche Domains betreibst du? Wo laufen Zertifikate? Sind Renewals automatisiert?
  • Kurzfristig (2026): Alle manuell verwalteten Zertifikate auf ACME-Automatisierung umstellen. Let's Encrypt oder ACME-API des bisherigen Anbieters.
  • Mittelfristig (2027): Monitoring einrichten. Sicherstellen dass alle Renewal-Prozesse zuverlässig laufen und Fehler gemeldet werden.
  • Langfristig (bis 2029): Renewal-Schwellwerte anpassen, Wildcard-Zertifikate über DNS-01 automatisieren, interne PKI-Prozesse überdenken.

Fazit

Die Verkürzung auf 40 Tage ist kein bürokratischer Akt — es ist die logische Konsequenz aus dem Versagen von Zertifikatsrevokation in der Praxis und ein notwendiger Schritt in Richtung kryptographischer Agilität. Wer Automatisierung heute implementiert, wird die Änderung kaum bemerken. Wer weiterhin manuell verwaltet, steht in drei Jahren vor einem echten Operationalproblem.

Let's Encrypt hat bewiesen: Automatisiertes Zertifikatsmanagement funktioniert, ist kostenlos und ist heute bereits Standard für Millionen von Domains. Die CA/B-Forum-Entscheidung zwingt nur den letzten Rest der Industrie, nachzuziehen.

Certbot vs. acme.sh vs. Caddy: Welche ACME-Implementierung?

Die Zertifikatserneuerung erfolgt über das ACME-Protokoll. Es gibt mehrere Implementierungen, die unterschiedliche Stärken haben:

Certbot (EFF) ist die Referenzimplementierung — am weitesten verbreitet, gut dokumentiert, viele Plugins für verschiedene Webserver. Wird mit den meisten Distributionen ausgeliefert. Renewal-Hook-System erlaubt Aktionen nach erfolgreicher Erneuerung.

acme.sh ist ein reines Shell-Skript ohne Abhängigkeiten — ideal für Systeme wo Python nicht verfügbar ist, und bekannt für seine breite DNS-Provider-Integration (über 100 DNS-Anbieter unterstützt für DNS-01-Challenge).

Caddy hat HTTPS vollständig integriert — keine separate Konfiguration nötig, Caddy holt sich automatisch Zertifikate für alle konfigurierten Domains beim Start. Für neue Deployments oft die einfachste Wahl.

# acme.sh mit Hetzner DNS für Wildcard-Zertifikate
export HETZNER_Token="dein-hetzner-dns-api-token"

acme.sh --issue   --dns dns_hetzner   -d "*.example.com"   -d "example.com"

# Zertifikat installieren
acme.sh --install-cert -d "*.example.com"   --cert-file /etc/ssl/example.com.crt   --key-file /etc/ssl/example.com.key   --reloadcmd "systemctl reload nginx"

Wildcard-Zertifikate bei 40-Tage-Limit

Wildcard-Zertifikate (*.example.com) können nur über die DNS-01-Challenge ausgestellt werden — HTTP-01 funktioniert nicht für Wildcards. Bei 40-tägiger Gültigkeit bedeutet das: Alle 30 Tage (mit Puffer) läuft die DNS-01-Challenge automatisch. Das funktioniert nur wenn der DNS-Anbieter eine API hat und acme.sh/certbot-Plugin dafür existiert.

Hetzner DNS hat eine vollständige API und wird von beiden Tools unterstützt. Cloudflare ebenfalls. Für selbst gehostete Nameserver (BIND, PowerDNS) gibt es acme.sh-Hooks für nsupdate (RFC 2136).

Zertifikats-Inventory: Was läuft wo ab wann?

Bei mehreren Servern und Domains ist ein Überblick über alle Zertifikate und ihre Ablaufdaten wichtig. Einfaches Monitoring-Skript:

# check_certs.sh: Alle Zertifikate auf Ablauf prüfen
#!/bin/bash
DOMAINS="example.com mail.example.com api.example.com nextcloud.example.com"
WARN_DAYS=30

for DOMAIN in $DOMAINS; do
    EXPIRY=$(echo | openssl s_client -servername $DOMAIN       -connect $DOMAIN:443 2>/dev/null |       openssl x509 -noout -enddate 2>/dev/null |       cut -d= -f2)
    if [ -z "$EXPIRY" ]; then
        echo "ERROR: $DOMAIN nicht erreichbar"
        continue
    fi
    EXPIRY_TS=$(date -d "$EXPIRY" +%s)
    NOW_TS=$(date +%s)
    DAYS_LEFT=$(( (EXPIRY_TS - NOW_TS) / 86400 ))
    if [ $DAYS_LEFT -lt $WARN_DAYS ]; then
        echo "WARNUNG: $DOMAIN läuft in $DAYS_LEFT Tagen ab ($EXPIRY)"
    else
        echo "OK: $DOMAIN — $DAYS_LEFT Tage verbleibend"
    fi
done

Browser-Verhalten bei abgelaufenen Zertifikaten

Mit kürzeren Zertifikatslaufzeiten steigt das Risiko, ein Zertifikat zu verpassen das nicht automatisch erneuert wurde. Was passiert dann im Browser? Chrome und Firefox zeigen eine nicht überspringbare Fehlerseite ("NET::ERR_CERT_DATE_INVALID") — kein "Anyway"-Button mehr seit Jahren. Mobil-Browser verhalten sich ähnlich. Das bedeutet: Ein abgelaufenes Zertifikat ist ein vollständiger Ausfall des Dienstes für alle Nutzer.

Daher ist Monitoring nicht optional. Die Kombination aus: automatischer Erneuerung (certbot timer oder cron), Monitoring des Zertifikats-Ablaufdatums, und einer Benachrichtigungs-E-Mail bei Fehlschlag ist das Minimum für produktive Systeme.

Was das für den Betrieb bedeutet: Abschließende Gedanken

Die Verkürzung auf 40 Tage ist ein Beschleuniger für etwas, das sowieso hätte passieren müssen: vollautomatische Zertifikatsverwaltung als Standard statt als Ausnahme. Wer noch manuell Zertifikate verwaltet — sei es weil ein Anbieter oder ein Hoster das so macht — muss jetzt handeln.

Die Werkzeuge für Automatisierung sind ausgereift, kostenlos und gut dokumentiert. Certbot, acme.sh, Caddy — alle lösen das Problem zuverlässig. Die Frage ist nicht ob man auf automatische Erneuerung wechselt, sondern wann. Wer es vor dem offiziellen Stichtag 2026 tut, tut es kontrolliert und in Ruhe. Wer wartet, tut es im Stress nach dem ersten Ausfall.

Die eigentliche Botschaft hinter der 40-Tage-Regel: Die CA/Browser-Community will, dass niemand mehr von Hand mit Zertifikaten umgeht. Das ist die richtige Richtung — manuell verwaltete Zertifikate sind eine der häufigsten Ursachen für unerwartete HTTPS-Ausfälle. Automatisierung ist die Lösung, und sie ist heute einfacher als je zuvor.

Für alle die noch manuell Zertifikate verwalten, ist jetzt der richtige Zeitpunkt für den Wechsel. Tools wie Certbot und acme.sh richten sich in einer Stunde ein, laufen dann zuverlässig als Systemdienst, und die einzige danach noch anfallende Aufgabe ist das gelegentliche Prüfen der Renewal-Logs. Die Alternative — ein abgelaufenes Zertifikat das den Dienst für alle Nutzer sperrt — ist keine akzeptable Alternative mehr.

Letzte Empfehlung: Den Renewal-Status aller Zertifikate in einem einfachen Monitoring-Skript erfassen und wöchentlich automatisch prüfen lassen. Eine E-Mail-Benachrichtigung bei Problemen kostet einen Nachmittag Einrichtung und verhindert Ausfälle zuverlässig.

War dieser Beitrag hilfreich?

Alle Beiträge Gregor Krebs · 9. Juni 2026