← Zurück zu News 20.10.2026

Bei 47 Tagen erneuert niemand mehr von Hand

Öffentliche TLS-Zertifikate dürfen seit März 2026 höchstens 200 Tage gelten, ab März 2027 100 und ab März 2029 nur noch 47. Was der Fahrplan des CA/Browser Forums für den Betrieb bedeutet, welche Systeme zum Problem werden und was bis zu den 100 Tagen erledigt sein sollte.

Bis März 2026 durfte ein öffentlich vertrauenswürdiges TLS-Zertifikat 398 Tage gelten. Seit dem 15. März 2026 sind es höchstens 200 Tage. Ab dem 15. März 2027 sind es 100, ab dem 15. März 2029 noch 47. So steht es in den Baseline Requirements des CA/Browser Forums, an die sich jede Zertifizierungsstelle halten muss, deren Zertifikaten die Browser vertrauen:

„Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.“

Beschlossen wurde der Fahrplan im April 2025 mit Ballot SC-081. Er verkürzt nicht nur die Laufzeit. Auch der Nachweis, dass Sie die Domain kontrollieren, darf nur noch begrenzt wiederverwendet werden: bis März 2026 waren es 398 Tage, seitdem sind es 200, ab März 2029 noch zehn Tage.

Was das an Arbeit bedeutet

Ein Zertifikat mit einem Jahr Laufzeit tauscht man einmal im Jahr. Bei 47 Tagen, mit dem üblichen Puffer vor dem Ablauf, sind es zehn bis zwölf Wechsel im Jahr, für jedes einzelne Zertifikat. Ein Haus mit 60 öffentlichen Zertifikaten kommt so auf rund 600 Wechsel im Jahr, zwei bis drei an jedem Arbeitstag.

Von Hand ist das nicht zu schaffen. Der Weg ist ACME, das Protokoll aus RFC 8555, mit dem ein Server sein Zertifikat selbst beantragt und erneuert. Die meisten Webserver und Reverse-Proxys können das. Das Problem sind die anderen: Appliances, Load Balancer, Telefonanlagen, Fachanwendungen mit eigener Weboberfläche, in die das Zertifikat bisher per Upload kam, einmal im Jahr, von jemandem, der wusste, wo die Maske ist.

Zertifikate aus einer eigenen, internen PKI betrifft der Fahrplan nicht. Die Baseline Requirements gelten nur für öffentlich vertrauenswürdige Zertifikate. Wer ein System deshalb auf interne Zertifikate umstellt, muss dann aber dafür sorgen, dass alle Clients der internen Zertifizierungsstelle vertrauen.

Was bis März 2027 erledigt sein sollte

Das Inventar. Nicht die Liste aus dem letzten Projekt, sondern das, was ein Scan tatsächlich findet. Ein Zertifikat, von dem niemand weiß, läuft auch unbemerkt ab.
Eine verantwortliche Person je Zertifikat. Eine Ablaufwarnung an ein Sammelpostfach ist bei zehn Wechseln im Jahr keine Warnung mehr, sondern Rauschen.
Die Trennung: automatisch oder von Hand. Die zweite Liste ist die Arbeitsliste, und sie muss kürzer sein, bevor die 100 Tage greifen.
Für jedes System auf dieser Liste eine Entscheidung. ACME nachrüsten, TLS an einem vorgeschalteten Proxy beenden, das System ersetzen oder bewusst auf ein internes Zertifikat umstellen.
Die Domainvalidierung. Mit zehn Tagen Wiederverwendung ab 2029 läuft die Prüfung praktisch bei jeder Ausstellung neu. Wer DNS-Einträge per Ticket beim Provider ändern lässt, braucht dafür eine Schnittstelle.

Wie isidaten das abbildet

Das Zertifikatsmanagement erneuert keine Zertifikate. Es ist das Inventar und die Warnung. Zertifikate, die das Attack Surface Management findet, werden jede Nacht übernommen. Stammt ein Zertifikat von einer ACME-Zertifizierungsstelle, wird es als automatisch erneuert geführt, alle anderen als manuell. Ebenfalls jede Nacht prüft das Modul den Ablauf in den Stufen Warnung (Standard 30 Tage vorher), kritisch (7 Tage) und abgelaufen und schreibt die verantwortliche Person an. Fehlt sie, geht die Warnung an alle mit Zugriff auf die Zertifikate.