TLS-Zertifikate 2026: Warum 200 Tage jetzt zum Problem werden
Wer heute noch öffentliche TLS-Zertifikate manuell verlängert, sollte sich langsam nach einer anderen Lösung umsehen. Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate nach den neuen Regeln des CA/Browser Forums maximal 200 Tage gültig sein. Ab März 2027 werden daraus 100 Tage, 2029 nur noch 47. Und Let’s Encrypt geht bei den eigenen Profilen sogar noch schneller voran.
398 → 200 → 100 → 47 Tage
DER ZEITPLAN
Von 398 auf 200 Tage – und danach weiter
Das CA/Browser Forum hat mit dem Ballot SC081v3 einen festen Zeitplan für die Verkürzung der maximalen Zertifikatslaufzeiten beschlossen, mit großer Mehrheit angenommen, unter anderem von den großen Browser-Anbietern.
bis 14.03.2026
Maximal 398 Tage, der bisherige Standard.
ab 15.03.2026
Maximal 200 Tage. Diese erste Stufe ist bereits aktiv.
ab 15.03.2027
Maximal 100 Tage.
ab 15.03.2029
Maximal 47 Tage, die letzte Stufe.
Das sind Maximalwerte, keine Pflichtwerte
Eine CA darf weiterhin kürzere Zertifikate ausstellen. DigiCert beispielsweise stellt seit Februar 2026 Zertifikate mit maximal 199 Tagen aus, einen Tag weniger als das CA/Browser-Forum-Maximum. Wer heute ein neues öffentliches Zertifikat beantragt, bekommt also nicht mehr automatisch die früher möglichen 398 Tage.
HINTERGRUND
Warum werden die Zertifikate überhaupt kürzer?
Die Verkürzung hat nicht den Grund, dass RSA oder TLS plötzlich unsicher geworden wären. Das CA/Browser Forum nennt mehrere Gründe.
Der Zustand veraltet
Ein Zertifikat beschreibt einen bestimmten Zustand zum Zeitpunkt der Ausstellung, etwa Domainbesitz oder Kontrolle über Systeme. Je länger es gültig bleibt, desto größer die Wahrscheinlichkeit, dass sich dieser Zustand verändert.
Reaktionsfähigkeit der Web-PKI
Stellt eine CA falsch aus, wird ein Schlüssel kompromittiert oder muss ein Verfahren ersetzt werden, ist es hilfreich, wenn alte Zertifikate nicht noch jahrelang gültig bleiben.
Automatisierung als Nebeneffekt
Das Forum nennt die Automatisierung des Zertifikatslebenszyklus ausdrücklich als erwarteten Nebeneffekt: Ausstellung, Austausch und Rotation sollen zuverlässiger automatisiert werden.
DIE EIGENTLICHE HÜRDE
Erneuert ist nicht dasselbe wie übernommen
200 Tage sind noch kein echtes Problem, 47 Tage schon: Aus einer gelegentlichen Wartungsaufgabe wird ein laufender Prozess, gerade wenn ein Server gleichzeitig Zertifikate für www.example.de, mail.example.de, autodiscover.example.de, einen Reverse Proxy und mehrere Kunden-Domains verwendet.
Ein automatisierter Zertifikatsabruf allein reicht nicht. Erneuert Certbot erfolgreich das Zertifikat für mail.example.de, liegt es danach korrekt im Zertifikatsordner. Wenn Postfix oder Dovecot aber weiterhin das alte Zertifikat im Speicher halten, hat sich für den Client zunächst nichts geändert. Nach einer erfolgreichen Erneuerung muss deshalb je nach Software ein Reload oder eine andere Form der Übernahme erfolgen.
Certbot bietet dafür sogenannte deploy-hooks an, die nach einer erfolgreichen Erneuerung automatisch einen Webserver oder Maildienst neu laden. Postfix dokumentiert dafür postfix reload. Erst der komplette Ablauf ist wirklich automatisiert:
ACME → Zertifikat erneuern → Zertifikat installieren → Dienst neu laden → Funktion prüfenACME steht für Automatic Certificate Management Environment, das Protokoll, über das ein Client mit einer Zertifizierungsstelle kommuniziert. Let’s Encrypt ist dabei die Zertifizierungsstelle, Certbot ein möglicher Client, oft wird auch beides verwechselt. Certbot ist ausdrücklich für automatisierte Erneuerungen ausgelegt: certbot renew prüft die vorhandenen Zertifikate und erneuert nur, was ansteht, ausgeführt über systemd-Timer oder Cron. Ein sinnvoller Test nach der Einrichtung:
certbot renew --dry-runBEREITS AKTIV
Let’s Encrypt macht schon vor, was jetzt Standard wird
Für Let’s-Encrypt-Nutzer ist diese Entwicklung eigentlich nichts grundsätzlich Neues, und ein Teil davon läuft schon heute, nicht erst in der Zukunft.
Seit 15.01.2026
Ein optionales Profil mit rund sechs Tagen (160 Stunden) Laufzeit ist allgemein verfügbar, ohne Widerrufsprüfung, nicht als Standard gedacht.
Seit 13.05.2026
Das Opt-in-Profil „tlsserver“ stellt Zertifikate mit 45 Tagen Laufzeit aus. Wer es aktiv anfordert, kann es schon heute nutzen.
10.02.2027 / 16.02.2028
Das Standardprofil „classic“, das die meisten ACME-Clients ohne besondere Einstellung bekommen, wechselt am 10.02.2027 auf 64 Tage und am 16.02.2028 auf 45 Tage.
Bei der Domain-Validierung geht Let’s Encrypt noch weiter
Die Wiederverwendung einer Domain-Validierung sinkt beim Standardprofil von 30 Tagen auf 10 Tage (2027) und dann auf nur noch 7 Stunden (2028), deutlich unter das CA/Browser-Forum-Minimum von 10 Tagen, das dort erst 2029 gilt.
Wenn die Automatisierung einmal funktioniert, spielt es für den Administrator kaum noch eine Rolle, ob ein Zertifikat 200, 90 oder 45 Tage gültig ist. Genau das macht 47 Tage weniger dramatisch, als es klingt.
ZWEI EINORDNUNGEN
Mailserver und interne Zertifikate
Was ändert sich für Mailserver?
Ein öffentliches Zertifikat wird oft gleichzeitig für SMTP, IMAP, Webmail und Autodiscover verwendet. Bei einem einzelnen Webserver reicht meist:
ACME → Zertifikat → nginx reloadBei einem Mailserver kann daraus schnell werden:
ACME → Zertifikat → Postfix → Dovecot → Webmail → weitere DiensteWer bisher einmal im Jahr manuell eine Zertifikatsdatei kopiert hat, sollte diesen Ablauf jetzt sauber durchplanen.
Und was ist mit internen Zertifikaten?
Die neuen Laufzeitvorgaben gelten für Zertifikate, die unter die TLS Baseline Requirements für öffentlich vertrauenswürdige Serverzertifikate fallen, also für Server, die über das Internet erreichbar sind. Eine eigene interne CA ist davon nicht automatisch betroffen: Wer für ein Homelab eine eigene PKI betreibt und deren Root-CA auf den eigenen Geräten verteilt, kann weiterhin eigene Laufzeiten festlegen. Für öffentlich erreichbare Webseiten, Mailserver und andere Dienste mit öffentlich vertrauenswürdigen Zertifikaten sieht es dagegen anders aus.
CHECKLISTE
Was Administratoren jetzt prüfen sollten
Wenn noch irgendwo Zertifikate manuell verlängert werden, würden wir nicht bis 2027 oder 2029 warten. Eine kleine Bestandsaufnahme reicht zunächst:
Welche öffentlichen Zertifikate gibt es?
Nicht nur Webseiten: auch Mailserver, Reverse Proxies, VPN-Portale, Monitoring-Systeme und Webinterfaces.
Wer stellt sie aus?
Let’s Encrypt, DigiCert, Sectigo oder eine andere öffentliche CA?
Wie werden sie erneuert?
ACME, Hosting-Panel, manuell per Datei oder per E-Mail-Erinnerung?
Wie kommt das neue Zertifikat zum Dienst?
Die Ausstellung allein zu automatisieren reicht nicht.
Wird der Dienst neu geladen?
Das sollte fester Teil des automatisierten Ablaufs sein.
Was passiert bei einem Fehler?
Ein fehlgeschlagener ACME-Lauf darf nicht erst auffallen, wenn der Browser ein abgelaufenes Zertifikat meldet.
Gibt es einen Ablauf-Test?
Certbot bietet dafür –dry-run zur Prüfung des späteren Renewal-Ablaufs.
FAZIT
Zertifikate werden zur laufenden Aufgabe – aber nicht für den Administrator
Die 200 Tage sind nicht das eigentliche Problem. Das Problem ist ein manueller Prozess. Seit März 2026 gilt für öffentliche TLS-Zertifikate ein Maximum von 200 Tagen, 2027 werden daraus 100 Tage, 2029 nur noch 47. Auch in aktuellen Diskussionen unter Administratoren zeigt sich ein einheitliches praktisches Problem: Nicht die Ausstellung eines neuen Zertifikats ist die größte Herausforderung, sondern die Systeme, die es anschließend übernehmen müssen, insbesondere die Verteilung an mehrere Dienste und deren Neuladen.
Wer heute noch jedes Zertifikat einzeln bestellt, herunterlädt, auf den Server kopiert und anschließend Dienste neu startet, sollte diesen Ablauf automatisieren. ACME, Certbot, integrierte Lösungen in Reverse Proxies oder Funktionen des Hosting-Panels machen das möglich.
Das Ziel ist nicht, sich einen Termin für die nächste Zertifikatsverlängerung in den Kalender zu schreiben. Das Ziel ist, dass man überhaupt keinen Termin mehr braucht. Wenn die Erneuerung funktioniert, das neue Zertifikat automatisch verteilt wird, die betroffenen Dienste neu laden und ein Monitoring Fehler meldet, spielt die maximale Laufzeit irgendwann keine große Rolle mehr. Dann sind 200 Tage kein Problem. 100 Tage auch nicht. Und 47 Tage ebenfalls nicht.
FAQ
Häufige Fragen zu den neuen Laufzeiten
QUELLEN
Quellen und Links
- CA/Browser Forum: Ballot SC081v3 (Zeitplan zur Verkürzung von Zertifikatslaufzeit und Domain-Validation-Reuse)
- DigiCert: Umstellung auf 199 Tage maximale Laufzeit seit Februar 2026
- Let’s Encrypt: Ankündigung zur Verkürzung der Zertifikatslaufzeiten (Profile tlsserver, shortlived, classic)
- Certbot-Dokumentation: deploy-hooks und certbot renew
Zertifikatsverwaltung automatisieren?
Ob ACME-Automatisierung, Mailserver oder Reverse Proxy: Nutzen Sie unsere IT-Leistungen.
