Das Wichtigste in Kürze
- Die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate sinkt gestaffelt: 200 Tage seit dem 15. März 2026, 100 Tage ab dem 15. März 2027, 47 Tage ab dem 15. März 2029.
- Parallel sinkt die Wiederverwendbarkeit der Domainvalidierung auf dieselben Werte und ab 2029 auf zehn Tage. Die Prüfung wird damit fast bei jeder Ausstellung fällig.
- Bei 47 Tagen erneuert man rund achtmal so oft wie im bisherigen 398-Tage-Rhythmus. Manuelle Verlängerung ist dann keine Sparmaßnahme mehr, sondern ein Ausfallrisiko.
- Im Netz hängen die unauffälligen Zertifikate: Geräte-Weboberflächen, WLAN-Controller, Gastportale, RADIUS-Serverzertifikate für EAP-TLS, VPN-Gateways und Management-Plattformen.
Zertifikate gelten als gelöstes Problem: Man kauft eines, trägt es ein, setzt eine Kalendererinnerung und hat ein Jahr Ruhe. Genau dieses Modell wird gerade abgeschafft — nicht auf einen Schlag, sondern in drei Stufen, von denen die erste bereits läuft.
Die Staffel und wo wir darin stehen
Das CA/Browser Forum hat im April 2025 beschlossen, die maximale Gültigkeit öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise zu senken. Ebenso verkürzt sich die Frist, in der eine einmal durchgeführte Domainvalidierung wiederverwendet werden darf.
| Ab | Maximale Laufzeit | Wiederverwendung der Domainvalidierung |
|---|---|---|
| bis 15. März 2026 | 398 Tage | 398 Tage |
| 15. März 2026 | 200 Tage | 200 Tage |
| 15. März 2027 | 100 Tage | 100 Tage |
| 15. März 2029 | 47 Tage | 10 Tage |
Zusätzlich gilt seit dem 15. März 2026, dass die Prüfung der Organisationsangaben (Subject Identity Information) nur noch 398 statt 825 Tage wiederverwendet werden darf — das betrifft OV- und EV-Zertifikate, also genau die Klasse, die in Unternehmen häufig für Portale und Dienste eingesetzt wird.
Wo es im Netz weh tut
Die Diskussion dreht sich meist um Webserver. Dort ist die Automatisierung seit Jahren üblich, und der Schmerz hält sich in Grenzen. Die unangenehmen Zertifikate liegen woanders — nämlich überall dort, wo ein Netzwerkgerät selbst TLS terminiert:
- Weboberflächen von Switches, Routern und Firewalls. Meist mit selbstsigniertem oder intern ausgestelltem Zertifikat, oft seit Inbetriebnahme unverändert.
- WLAN-Controller und Gastportale. Ein abgelaufenes Portalzertifikat erzeugt keine Fehlermeldung im Monitoring, sondern eine Warnseite auf jedem Endgerät im Gebäude.
- RADIUS-Serverzertifikate für EAP-TLS. Läuft dieses ab, meldet sich schlagartig kein Client mehr am WLAN oder am 802.1X-geschützten Port an — der lauteste denkbare Ausfall.
- VPN-Gateways und Fernzugänge. Hier trifft der Ablauf zuerst die Menschen, die von außen arbeiten, und damit typischerweise ausgerechnet die Bereitschaft.
- Management-Plattformen und Controller. Sie sprechen untereinander TLS; ein abgelaufenes Zertifikat unterbricht nicht den Datenverkehr, aber die Steuerung.
Die Reihenfolge, die trägt
Der Reflex ist, ein Zertifikatsmanagement zu beschaffen. Der wirksamere erste Schritt ist banaler und kostet nichts außer Zeit: herausfinden, wie viele Zertifikate es überhaupt gibt und wer sie erneuert.
Zertifikatsinventar
Jede TLS-terminierende Stelle mit Aussteller, Ablaufdatum, Verantwortlichem und Erneuerungsweg. Aktiv erhoben — durch Abfrage der Endpunkte, nicht durch Umfrage.
Klassifikation
Öffentlich vertrauenswürdig oder intern? Nur die erste Klasse unterliegt der Staffel, aber die zweite bestimmt, wie viele Verfahren Sie am Ende betreiben.
Automatisierungspfad je Klasse
ACME für alles, was es kann; EST oder SCEP dort, wo Netzwerkgeräte und interne PKI aufeinandertreffen. Entscheidend ist nicht das Protokoll, sondern dass je Klasse genau eines gilt.
Ausnahmen benennen
Es bleiben Geräte, die keine Automatisierung können. Die gehören auf eine kurze, begründete Liste mit Termin — nicht in den stillen Restbestand.
Überwachung auf Ablauf
Ein Alarm, der 30 Tage vorher meldet, ist bei 47-Tage-Zertifikaten ein Dauerton. Die Schwelle gehört an die Laufzeit gekoppelt, nicht an eine feste Zahl.
Warum das ein Automatisierungsthema ist
Die Verkürzung ist kein Sicherheitsproblem, das man mit mehr Sorgfalt löst. Sie ist eine Frequenzänderung, und Frequenz löst man mit Wiederholbarkeit. Ein Zertifikatswechsel, der als Change durch dieselbe Strecke läuft wie jede andere Konfigurationsänderung — versioniert, getestet, protokolliert —, ist bei 47 Tagen genauso wenig aufwendig wie bei 398.
Das ist derselbe Grundsatz, den wir unter Network Automation beschreiben: Der Aufwand einer Aufgabe entscheidet sich nicht daran, wie schwer sie ist, sondern daran, wie oft sie von Hand gemacht wird. Wie die Zertifikatslage in ein Gesamtbild des Netzes passt, steht unter Unternehmensnetze.
Was jetzt zu tun ist
Die 200-Tage-Stufe läuft bereits. Wer heute ein Zertifikat mit einjähriger Laufzeit bestellt, bekommt keines mehr. Das ist die einfachste Gelegenheit, das Inventar zu erstellen: Die nächste Erneuerungswelle kommt ohnehin früher als geplant — sie kann gleich mit der Aufnahme verbunden werden.
Der zweite Termin ist der 15. März 2027. Bis dahin sollte jede Klasse einen automatisierten Weg haben, und die Ausnahmeliste sollte kürzer sein als heute. Wer erst 2029 anfängt, macht die Umstellung unter Ausfalldruck statt in Ruhe.
Quellen
Jede belegte Aussage dieses Beitrags ist hier nachvollziehbar. Das Abrufdatum sagt, wie frisch die Prüfung ist.
- TLS Certificate Lifetimes Will Officially Reduce to 47 Daysöffnet in neuem Tab
DigiCert · abgerufen am 2. August 2026
- Preparing for 47-Day SSL/TLS Certificates: What You Need to Knowöffnet in neuem Tab
SSL.com · abgerufen am 2. August 2026
- CA/Browser Forum Certificate Validity Changesöffnet in neuem Tab
AppViewX · abgerufen am 2. August 2026
- CA/B Forum Cuts SSL/TLS Certificate Lifespan to 47 Daysöffnet in neuem Tab
Sectigo · abgerufen am 2. August 2026

