47-Tage-Zertifikate: Der CA/Browser-Fahrplan bis 2029

Die Diskussion ist entschieden, und ein Teil davon ist bereits Betriebsrealität: Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate höchstens 200 Tage gültig sein, nicht mehr 398. Das ist die erste Stufe eines Fahrplans, den das CA/Browser-Forum im April 2025 mit Ballot SC-081v3 beschlossen hat: einstimmig, mit 29 Ja-Stimmen und keiner Gegenstimme. Am Ende dieses Fahrplans steht eine maximale Laufzeit von 47 Tagen.

Wer Zertifikate noch von Hand bestellt und im Kalender notiert, sollte die nächsten drei Jahre als Umbauprojekt einplanen, nicht als Reihe von Einzelterminen.

Der Fahrplan in Zahlen

Die maximale Gültigkeit sinkt in klar terminierten Stufen:

• bis 14. März 2026: 398 Tage (der bisherige Standard)
• ab 15. März 2026: 200 Tage (gilt heute)
• ab 15. März 2027: 100 Tage
• ab 15. März 2029: 47 Tage

Parallel, und das ist der operativ anspruchsvollere Teil, verkürzt sich die Wiederverwendbarkeit der Domain-Validierung (Domain Control Validation, DCV). Die einmal geprüfte Kontrolle über eine Domain darf künftig deutlich kürzer „nachgenutzt" werden, bevor sie erneut bestätigt werden muss:

• ab 15. März 2026: 200 Tage
• ab 15. März 2027: 100 Tage
• ab 15. März 2029: 10 Tage

Für OV- und EV-Zertifikate sinkt zusätzlich die Wiederverwendbarkeit der geprüften Organisationsdaten (Subject Identity Information) zum 15. März 2026 von 825 auf 398 Tage.

Die 47 Tage sind also nur die Schlagzeile. Die 10 Tage DCV-Reuse ab 2029 sind der eigentliche Taktgeber: Ab dann muss faktisch alle zehn Tage neu nachgewiesen werden, dass die Domain noch unter eigener Kontrolle steht.

Warum die Verkürzung kommt

Hinter dem Schritt steht eine einfache Sicherheitslogik. Ein Zertifikat ist eine Vertrauensaussage mit Verfallsdatum. Je länger es gültig ist, desto länger wirkt eine Fehlausstellung, ein kompromittierter Schlüssel oder ein veralteter kryptografischer Parameter fort. Der klassische Gegenmechanismus, die Sperrung über CRL und OCSP, funktioniert in der Praxis unzuverlässig: Sperrlisten werden nicht überall zeitnah ausgewertet, OCSP wird zunehmend abgekündigt. Kurze Laufzeiten ersetzen die Sperrung durch das Ablaufen. Ein Problem heilt sich, weil das betroffene Zertifikat ohnehin bald ungültig wird.

Der zweite Treiber ist Krypto-Agilität. Wer Zertifikate regelmäßig erneuert, kann Algorithmen, Schlüssellängen und Profile im laufenden Betrieb wechseln, eine Grundvoraussetzung für die anstehende Migration zu Post-Quantum-Verfahren. Lange Laufzeiten zementieren dagegen den Status quo.

Was das für den Betrieb bedeutet

Die zentrale Folge ist banal und unausweichlich: Manuelle Erneuerung skaliert nicht mehr. Ein 47-Tage-Zertifikat wird, mit vernünftigem Puffer, etwa alle 30 Tage ausgetauscht. Über einen mittelgroßen Bestand hinweg ist das kein Kalendereintrag mehr, sondern ein Prozess, der ohne menschliches Zutun laufen muss.

Drei Fähigkeiten entscheiden darüber, ob dieser Umbau gelingt:

Automatisierung. ACME (RFC 8555) ist der etablierte Standard für automatische Ausstellung und Erneuerung, nicht nur für Let’s Encrypt, sondern zunehmend auch für kommerzielle und interne CAs. Wo ACME nicht greift, braucht es API-gestützte Renewal-Workflows mit Approval, damit Compliance-Kontrollen erhalten bleiben.

Discovery. Automatisieren lässt sich nur, was man kennt. Der typische Ausfall im Jahr 2029 wird nicht das gut gepflegte Zertifikat auf dem Hauptsystem sein, sondern das vergessene auf einem Load-Balancer-Endpoint, einer Appliance oder in einem Cloud-Account, den niemand mehr auf dem Schirm hat. Aktive Netzscans und passive Cloud-Discovery sind die Voraussetzung dafür, dass kurze Laufzeiten nicht zu kurzfristigen Ausfällen werden.

Eigentümerschaft. Jedes Zertifikat braucht einen klar zugeordneten Verantwortlichen, eine bekannte CA und ein hinterlegtes Erneuerungsverfahren. Ein Inventar, das diese drei Angaben pro Zertifikat führt, ist die eigentliche Versicherung gegen die 47-Tage-Realität.

Genau dieses Muster (Discovery zuerst, dann CA-agnostische Automatisierung mit Approval) liegt unserem Modul NextPKI zugrunde. Die regulatorische Stoßrichtung ist davon unabhängig: Wer den Bestand sichtbar macht und die Erneuerung automatisiert, ist vorbereitet, ganz gleich mit welchem Werkzeug.

Was jetzt sinnvoll ist

Drei Jahre klingen nach viel Zeit, aber die 200-Tage-Stufe läuft bereits. Konkret lohnt sich jetzt: ein vollständiges Inventar aller TLS-Zertifikate über Netz, Cloud und Endpunkte hinweg; die Identifikation aller Stellen, an denen heute noch manuell erneuert wird; ein Pilot mit ACME-basiertem Auto-Renewal auf unkritischen Diensten; und die Klärung, welche internen Systeme bis 2029 zehntägige Domain-Revalidierung technisch überhaupt mittragen können.

Die 47 Tage kommen nicht überraschend und nicht auf einmal. Sie kommen in Stufen, und die erste steht bereits.