TLS-Zertifikate: Die 200-Tage-Ära hat begonnen

Seit dem 15. März 2026 dürfen neu ausgestellte, öffentlich vertrauenswürdige TLS-Serverzertifikate höchstens 200 Tage gültig sein. Damit ist die erste Stufe eines mehrjährigen Umbaus der Web-PKI in Kraft getreten. Im März 2027 sinkt die maximale Laufzeit auf 100 Tage, ab März 2029 bleiben nur noch 47 Tage.

Für Unternehmen wird automatisiertes Zertifikatsmanagement damit von einer Best Practice zur betrieblichen Notwendigkeit.

Erste Verkürzungsstufe gilt bereits

Grundlage der Änderung ist das im April 2025 angenommene Ballot SC081v3 des CA/Browser Forum. Für den Vorschlag stimmten 25 Zertifizierungsstellen, fünf enthielten sich. Aufseiten der sogenannten Certificate Consumers votierten Apple, Google, Microsoft und Mozilla geschlossen dafür.

Der Beschluss betrifft Zertifikate, die ab dem jeweiligen Stichtag ausgestellt werden. Seit dem 15. März 2026 liegt die Obergrenze bei 200 Tagen. Am 15. März 2027 folgt die Reduzierung auf 100 Tage, bevor ab dem 15. März 2029 maximal 47 Tage zulässig sind.

Vor dem ersten Stichtag ausgestellte Zertifikate verlieren ihre Gültigkeit nicht vorzeitig. Sie können bis zu ihrem regulären Ablauf weiterverwendet werden.

Parallel verkürzt sich der Zeitraum, für den eine bereits erfolgte Domain- oder IP-Validierung bei einer erneuten Ausstellung wiederverwendet werden darf. Er beträgt derzeit 200 Tage, sinkt 2027 auf 100 Tage und 2029 auf zehn Tage.

Eine Zertifikatslaufzeit von 47 Tagen und eine Validierungsfrist von zehn Tagen sind dabei zwei getrennte Vorgaben.

Kürzere Laufzeiten sollen Risiken begrenzen

Das CA/Browser Forum begründet die Umstellung unter anderem damit, dass die in einem Zertifikat bestätigten Informationen mit zunehmendem Alter an Aktualität verlieren können.

Kürzere Laufzeiten begrenzen zudem den Zeitraum, in dem falsch ausgestellte Zertifikate oder Zertifikate mit kompromittierten Schlüsseln verwendet werden können. Außerdem sollen sie den Wechsel auf neue kryptografische Verfahren erleichtern.

Ein weiterer Grund sind die Grenzen klassischer Sperrverfahren wie Certificate Revocation Lists und OCSP. Diese Verfahren ermöglichen zwar eine vorzeitige Sperrung von Zertifikaten, liefern aber nicht in jedem Fall eine ausreichend schnelle und zuverlässige Reaktion über alle Systeme hinweg.

Der garantierte Ablauf eines Zertifikats schafft dagegen eine feste zeitliche Begrenzung – unabhängig davon, ob eine Sperrinformation alle betroffenen Systeme rechtzeitig erreicht.

Manuelle Prozesse werden zum Ausfallrisiko

Für Unternehmen steigt mit jeder Verkürzungsstufe die Zahl der notwendigen Ausstellungen, Validierungen und Installationen. Bei einer maximalen Laufzeit von 47 Tagen müssen Zertifikate deutlich vor ihrem Ablauf erneuert werden.

Manuell gepflegte Tabellen, Kalendererinnerungen und personenabhängige Abläufe sind dafür kaum belastbar.

Besonders relevant ist die Änderung für verteilte Infrastrukturen mit Load Balancern, API-Gateways, Kubernetes-Clustern, Cloud-Diensten, Firewalls, Mailservern und extern betriebenen Plattformen.

Eine erfolgreiche Ausstellung allein genügt nicht. Das neue Zertifikat muss rechtzeitig auf allen beteiligten Systemen installiert, aktiviert und überwacht werden. Fehler in diesem Prozess können Websites, APIs oder Integrationen unmittelbar unerreichbar machen.

Unternehmen sollten deshalb nicht nur die Erneuerung, sondern den gesamten Zertifikatslebenszyklus automatisieren. Dazu gehören:

• die Erfassung vorhandener Zertifikate,
• die Domainvalidierung,
• die Ausstellung,
• die sichere Verteilung,
• die Installation,
• technische Funktionstests,
• die Überwachung der verbleibenden Laufzeit.

Das CA/Browser Forum nennt eine stärkere Verbreitung stabiler Automatisierungsverfahren ausdrücklich als erwarteten Effekt der neuen Regeln.

Zusätzlicher Aufwand für OV und EV

Für Organization-Validated- und Extended-Validation-Zertifikate gilt seit dem 15. März 2026 eine weitere Änderung: Bereits geprüfte Unternehmens- und Identitätsdaten dürfen nur noch für maximal 398 statt bisher 825 Tage wiederverwendet werden.

Das betrifft beispielsweise Angaben zum Unternehmensnamen oder Geschäftssitz. Die eigentliche Zertifikatslaufzeit unterscheidet sich jedoch nicht von der anderer öffentlich vertrauenswürdiger TLS-Zertifikate.

Nicht unmittelbar betroffen sind Zertifikate aus einer rein internen PKI, deren Root-Zertifikat nicht über die Vertrauensspeicher von Browsern oder Betriebssystemen verteilt wird.

Die Vorgaben des CA/Browser Forum beziehen sich auf öffentlich vertrauenswürdige TLS-Zertifikate. Unternehmen müssen öffentliche und interne Zertifikatsbestände deshalb bei ihrer Planung sauber voneinander trennen.

Was IT-Entscheider jetzt prüfen sollten

Die aktuelle 200-Tage-Stufe ist noch mit gut organisierten Prozessen beherrschbar. Sie sollte jedoch nicht als Endzustand betrachtet werden.

Unternehmen benötigen spätestens vor März 2027 einen vollständigen Überblick über ihre öffentlich vertrauenswürdigen Zertifikate und deren technische Abhängigkeiten.

Entscheidend ist, ob Ausstellung, Validierung und Installation ohne regelmäßige manuelle Eingriffe funktionieren. Auch Systeme, Appliances oder externe Dienstleister ohne standardisierte Automatisierungsschnittstellen müssen in die Bewertung einbezogen werden.

Wer erst kurz vor der 47-Tage-Stufe mit dieser Bestandsaufnahme beginnt, riskiert unnötigen Zeitdruck und vermeidbare Ausfälle.

Die Verkürzung der Zertifikatslaufzeiten ist damit weniger ein Beschaffungsthema als eine Frage der Betriebsreife. Zertifikate müssen künftig wie andere kurzlebige Zugangsdaten automatisiert, zentral überwacht und eindeutig verantwortet werden.

Quellen

• CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
• CA/Browser Forum: Ballot SC081v3 – Introduce Schedule of Reducing Validity and Data Reuse Periods
• Borns IT- und Windows-Blog: TLS-Server-Zertifikate ab 2029 nur noch 47 Tage gültig
• BrandShelter: Kürzere SSL-Laufzeiten ab 2026