Zum Inhalt springen
CONFIGLANE

Kryptografie · Betrieb

Von 398 auf 47 Tage: Was kurze TLS-Zertifikate im Netz auslösen

Die Verkürzung ist beschlossen, gestaffelt und teilweise schon in Kraft. Sie trifft nicht nur Webserver — sie trifft jede Stelle im Netz, an der ein Zertifikat hängt, das heute jemand einmal im Jahr von Hand erneuert.

Von ConfiglaneVeröffentlicht 6 Min. LesezeitNetwork Automation

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.

AbMaximale LaufzeitWiederverwendung der Domainvalidierung
bis 15. März 2026398 Tage398 Tage
15. März 2026200 Tage200 Tage
15. März 2027100 Tage100 Tage
15. März 202947 Tage10 Tage
Maximale Laufzeit und Wiederverwendung der Domainvalidierung

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.

  1. Zertifikatsinventar

    Jede TLS-terminierende Stelle mit Aussteller, Ablaufdatum, Verantwortlichem und Erneuerungsweg. Aktiv erhoben — durch Abfrage der Endpunkte, nicht durch Umfrage.

  2. Klassifikation

    Öffentlich vertrauenswürdig oder intern? Nur die erste Klasse unterliegt der Staffel, aber die zweite bestimmt, wie viele Verfahren Sie am Ende betreiben.

  3. 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.

  4. 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.

  5. Ü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.

FAQ

Häufige Fragen zu kurzen Zertifikatslaufzeiten

Ab wann gelten 47 Tage für TLS-Zertifikate?

Die 47 Tage greifen ab dem 15. März 2029. Davor läuft eine Staffel: seit dem 15. März 2026 höchstens 200 Tage, ab dem 15. März 2027 höchstens 100 Tage. Wer heute plant, plant deshalb nicht gegen 2029, sondern gegen die 100-Tage-Stufe in gut einem Jahr — sie ist der eigentliche Bruch mit dem jährlichen Handbetrieb, weil eine Erneuerung dann mehrfach pro Jahr fällig wird.

Betrifft die Verkürzung auch unsere interne PKI?

Die Vorgabe des CA/Browser Forums bindet öffentlich vertrauenswürdige Zertifizierungsstellen. Eine unternehmenseigene PKI ist davon nicht erfasst und kann längere Laufzeiten ausstellen. Praktisch spricht dennoch einiges dafür, beide Welten auf einen automatisierten Prozess zu bringen: Zwei Verfahren nebeneinander bedeuten doppelte Pflege und die Gefahr, dass die manuelle Seite still veraltet.

Was passiert, wenn ein Zertifikat auf einem Netzwerkgerät abläuft?

Das hängt vom Dienst ab. Bei einer Weboberfläche bekommen Sie eine Warnung und arbeiten weiter. Bei einem RADIUS-Serverzertifikat für EAP-TLS lehnen Clients die Anmeldung ab — das Netz wirkt dann von einer Minute auf die andere ausgefallen, obwohl kein Gerät gestört ist. Deshalb gehören diese Zertifikate ganz oben auf die Inventarliste.

Reicht ein Monitoring auf Ablaufdaten?

Als Sicherheitsnetz ja, als Lösung nein. Ein Alarm sagt Ihnen, dass jemand handeln muss — bei achtfacher Frequenz ist das achtfach so oft. Sinnvoll ist die Kombination: automatisierte Erneuerung als Regelfall, Ablaufüberwachung als Kontrolle, dass die Automatisierung tatsächlich gegriffen hat.

Welche Protokolle kommen für Netzwerkgeräte in Frage?

ACME ist der Standardweg für öffentlich vertrauenswürdige Zertifikate und wird zunehmend auch von Netzwerk- und Sicherheitsprodukten unterstützt. Im Zusammenspiel mit einer internen PKI sind EST und SCEP verbreitet. Entscheidend ist weniger die Wahl als die Festlegung: ein Weg je Geräteklasse, dokumentiert und getestet.

Nächster Schritt

Gilt das auch für Ihr Netz?

Ein Assessment beantwortet die Frage an Ihrer Infrastruktur statt an einem Beispiel — mit einem belastbaren ersten Change am Ende.

Assessment anfragen

Assessment → belastbarer erster Change