Stärkere Sicherheit durch TLS-Zertifikate mit 47-tägiger Gültigkeit bis 2029

Wenn Ihre Organisation heute öffentliche TLS-Zertifikate verwaltet und immer noch auf manuelle Erneuerungsprozesse, Kalendererinnerungen oder andere Verfahren angewiesen ist, bei denen ein Mensch ein bevorstehendes Ablaufdatum bemerken und Maßnahmen ergreifen muss, werden die nächsten drei Jahre wirklich disruptive Veränderungen mit sich bringen.

Am 11. April 2025 verabschiedete das CA/Browser Forum den Antrag SC-081v3 mit dem offiziellen Titel „Einführung eines Zeitplans zur Reduzierung der Gültigkeitsdauer und der Datenwiederverwendungszeiträume“. Das Ergebnis war eindeutig: 25 Zertifizierungsstellen stimmten dafür, keine dagegen , und alle vier großen Browserhersteller – Apple, Google, Microsoft und Mozilla – stimmten mit Ja. Das Ergebnis ist ein festgelegter, stufenweiser Zeitplan, der die maximale Gültigkeit aller öffentlich vertrauenswürdigen TLS-Zertifikate von derzeit 398 Tagen auf 47 Tage bis zum 15. März 2029 reduziert.

In diesem Blogbeitrag erläutern wir detailliert die Anforderungen von SC-081v3, die Gründe für diese Entscheidung des CA/Browser Forums, die betrieblichen Konsequenzen für Teams, die TLS-Zertifikate verwalten , und was Ihre Organisation jetzt tun sollte, um in jeder Phase einen Schritt voraus zu sein.

Was sich geändert hat und wann

Der Wahlvorschlag SC-081v3 wurde ursprünglich von Apple im Januar 2025 eingereicht. Die Frist für die Überprüfung der IP-Rechte endete am 13. Mai 2025 ohne Einwände, sodass der Wahlvorschlag ab diesem Datum vollumfänglich rechtskräftig ist.

Die Abstimmung ändert zwei Abschnitte der TLS-Basisanforderungen:

• Abschnitt 6.3.2: Legt den gestaffelten Zeitplan für die Reduzierung der maximalen Gültigkeitsdauer von TLS-Zertifikaten fest.
• Abschnitt 4.2.1: legt den parallelen Zeitplan für die Reduzierung der Zeitspanne fest, in der Domain Control Validation (DCV)-Nachweise zwischen Zertifikatsausstellungen wiederverwendet werden können.

Beide Änderungen treten in denselben drei Phasen in Kraft; jeweils am 15. März eines jeden Jahres:

Phase	Datum des Inkrafttretens	Maximale Gültigkeit des TLS-Zertifikats	DCV-Wiederverwendungszeitraum
Phase 1	15. März 2026	200 Tage	200 Tage
Phase 2	15. März 2027	100 Tage	100 Tage
Phase 3	15. März 2029	47 Tage	10 Tage

Bevor eine Zertifizierungsstelle (CA) ein TLS-Zertifikat für eine Domain ausstellen kann, muss sie zunächst überprüfen, ob der Antragsteller die Domain tatsächlich kontrolliert. Dies wird als Domainkontrollvalidierung bezeichnet. In der Praxis verlangt die CA vom Antragsteller die Erfüllung einer Herausforderung, typischerweise durch das Ablegen einer bestimmten Datei unter einer bekannten URL der Domain (HTTP-01), das Hinzufügen eines bestimmten DNS-TXT-Eintrags (DNS-01) oder die Beantwortung einer Validierungs-E-Mail an eine für die Domain registrierte Kontaktadresse. Sobald die CA die erfolgreiche Erfüllung der Herausforderung bestätigt hat, gilt die Domain als validiert. Früher konnte dieser Validierungsnachweis bis zu 398 Tage lang wiederverwendet werden, sodass eine CA über ein Jahr lang weitere Zertifikate für dieselbe Domain ausstellen konnte, ohne einen erneuten Nachweis zu verlangen.

SC-081v3 verkürzt dieses Wiederverwendungsfenster parallel zur Gültigkeitsdauer des Zertifikats und reduziert es bis März 2029 letztendlich auf nur noch 10 Tage. Ab diesem Zeitpunkt muss die Domaininhaberschaft bei nahezu jeder Zertifikatserneuerung erneut überprüft werden, wodurch die automatisierte DCV über das Challenge-Response-Protokoll von ACME zu einer zwingenden betrieblichen Anforderung und nicht mehr zu einer Optimierung wird.

Phase 1 ist ab heute in Kraft. Jedes neu ausgestellte TLS-Zertifikat hat eine maximale Gültigkeitsdauer von 200 Tagen. Zertifikate, die vor dem jeweiligen Phasenende ausgestellt wurden, behalten ihre ursprüngliche Gültigkeitsdauer. Alle Zertifikate, die am oder nach dem jeweiligen Phasenende ausgestellt werden, müssen die neue maximale Gültigkeitsdauer für diese Phase erfüllen, da es keine Übergangsfrist für neu ausgestellte Zertifikate gibt.

Warum das CA/Browser-Forum diese Entscheidung getroffen hat

Der Trend zu kürzeren Zertifikatsgültigkeitsdauern zeichnet sich seit Jahren ab. TLS-Zertifikate waren bis 2015 bis zu fünf Jahre gültig, dann reduzierte das CA/Browser Forum die Gültigkeitsdauer auf drei Jahre. 2018 sank das Maximum auf zwei Jahre. 2020 begrenzte Apple die Gültigkeitsdauer neuer Zertifikate in Safari einseitig auf 398 Tage und zwang damit die gesamte Branche, diese Beschränkung zu übernehmen.

• Begrenzung des Explosionsradius: Wird ein privater Schlüssel gestohlen, ein Zertifikat gefälscht ausgestellt oder ein Signaturalgorithmus als schwach erkannt, ist das Schadenspotenzial direkt proportional zur verbleibenden Gültigkeitsdauer des Zertifikats. Ein Zertifikat mit 47 Tagen Restgültigkeit bietet ein deutlich kleineres Zeitfenster für Missbrauch als eines mit 398 Tagen.
• Die Wirksamkeit des Widerrufs sicherstellen: Die Zertifikatssperrung ist in der Praxis weitgehend fehlerhaft. Das Online Certificate Status Protocol (OCSP) arbeitet in den meisten Browsern nach dem Soft-Fail-Prinzip, d. h., wenn der OCSP-Responder nicht erreichbar ist, wird die Verbindung in der Regel fortgesetzt, anstatt sie zu blockieren. Zertifikatssperrlisten (CRLsDie Protokolle werden nur selten aktualisiert und unregelmäßig überprüft. Let's Encrypt begann 2024 mit der vollständigen Abschaffung von OCSP und schloss diesen Übergang 2025 ab, da OCSP sich als ineffektiv erwiesen hatte.
• Stärkere kryptografische Verfahren: Langlebige Zertifikate ermöglichen es Organisationen, Algorithmusmigrationen hinauszuzögern. Ein Zertifikat, das 2023 mit einer zu geringen Schlüssellänge oder einem veralteten Algorithmus ausgestellt wurde, könnte 2026 noch im Einsatz sein, sofern seine Gültigkeit bis dahin reicht. Kürzere Gültigkeitsdauern erfordern häufigere Ausstellungen, wodurch sich mehr Möglichkeiten ergeben, aktuelle Algorithmus- und Schlüsselstandards anzuwenden.
• Erforderliche Automatisierung: Das CA/Browser Forum hat ausdrücklich erklärt, dass eines der Ziele von SC-081v3 die Förderung der automatisierten Zertifikatslebenszyklusverwaltung ist. Ein 47-Tage-Zertifikat, das alle sechs Wochen erneuert wird, ist mit manuellen Prozessen nicht vereinbar, da der operative Aufwand schlichtweg zu hoch ist. Daher ist dieser Prozess zuverlässiger, besser nachvollziehbar und robuster als jeder von Menschen abhängige Prozess.

Was 47-Tage-Zertifikate in der Praxis bedeuten

Die betrieblichen Konsequenzen von SC-081v3 variieren erheblich, je nach Größe und Komplexität Ihrer Zertifikatskonfiguration und dem aktuellen Stand Ihrer Zertifikatsverwaltungspraktiken.

Transparenz des Zertifikatsbestands

Sie können die Erneuerung von Zertifikaten nicht verwalten, deren Existenz Ihnen unbekannt ist. Die unkontrollierte Verbreitung von Zertifikaten, die über mehrere Teams, Cloud-Umgebungen, Kubernetes -Cluster, CDN-Konfigurationen und Legacy-Server ohne zentrale Nachverfolgung ausgestellt werden, ist die häufigste Ursache für Ausfälle aufgrund abgelaufener Zertifikate. Bei jährlichen Erneuerungszyklen kann ein unentdecktes Zertifikat monatelang unbemerkt bleiben, bevor es abläuft. Bei 47-Tage-Zyklen läuft ein nicht nachverfolgtes Zertifikat innerhalb weniger Wochen nach der Ausstellung ab.

Die Schaffung einer umfassenden Transparenz des Zertifikatsbestands über alle Umgebungen hinweg, einschließlich interner Dienste, nicht kundenorientierter Infrastruktur und von externen Teams oder Drittanbietern verwalteter Zertifikate, ist die grundlegende Voraussetzung für diese Aktualisierung der Gültigkeitsdauer von Zertifikaten.

CI/CD- und Bereitstellungsintegration

Eine der häufigsten Fehlerursachen in automatisierten Zertifikatsumgebungen ist die sogenannte „Erneuerungs-Bereitstellungs-Lücke“. Dabei erhält der ACME-Client zwar erfolgreich ein neues Zertifikat, doch die Installation auf dem entsprechenden Server, Load Balancer oder Kubernetes-Ingress schlägt unbemerkt fehl. Das erneuerte Zertifikat verbleibt im Dateisystem oder im Secrets Store, während das alte Zertifikat weiterhin Datenverkehr verarbeitet, bis es abläuft.

Bei einer Gültigkeitsdauer von 47 Tagen stellt die Lücke in der Bereitstellung einen kritischen Fehler dar. Die Zertifikatserneuerung muss in den Bereitstellungsprozess integriert werden, und das neue Zertifikat muss als bereitgestellt und im Datenverkehr aktiv verifiziert sein, bevor die Erneuerung als abgeschlossen gilt.

Legacy-Infrastruktur und Zertifikats-Pinning

Legacy-Anwendungen mit fest codierten Zertifikaten, IoT-Geräte mit in die Firmware eingebetteten Zertifizierungsstellen, Systeme, die Certificate Pinning verwenden, und Umgebungen mit manuellen Bereitstellungsprozessen stellen allesamt Punkte dar, bei denen 47-Tage-Zertifikate echte Herausforderungen darstellen, die sich nicht allein durch Automatisierung lösen lassen.

Certificate Pinning, bei dem ein Client so konfiguriert wird, dass er nur einem bestimmten Zertifikat oder öffentlichen Schlüssel vertraut, anstatt jedem Zertifikat einer vertrauenswürdigen Zertifizierungsstelle, ist grundsätzlich unvereinbar mit der 47-tägigen Gültigkeitsdauer. Muss das gepinnte Zertifikat alle sechs Wochen ersetzt werden, muss die Clientkonfiguration im gleichen Rhythmus aktualisiert werden. Die einzig praktikable Lösung für Umgebungen mit gepinntem Zertifikat ist die vollständige Umstellung von der Pinning-Methode auf die standardmäßige, CA-basierte Vertrauensprüfung, bevor die 47-tägige Gültigkeitsdauer in Kraft tritt.

Bereiten Sie sich auf die kürzere Gültigkeitsdauer des TLS-Zertifikats vor.

Da Phase 1 bereits angelaufen ist und Phase 2 im März 2027 beginnt, ist das Zeitfenster für den Aufbau der für die 47-tägige Phase benötigten Infrastruktur begrenzt. Hier ist eine praktische Abfolge für die Vorbereitung:

Schritt 1: Erstellen Sie ein vollständiges Zertifikatsverzeichnis.

Ermitteln Sie alle öffentlichen TLS-Zertifikate, die Ihr Unternehmen in allen Umgebungen und Teams ausgestellt hat. Nutzen Sie die Protokollüberwachung mittels Certificate Transparency (CT), APIs von Cloud-Anbietern, Netzwerkscans und Integrationen mit der Verwaltungskonsole Ihrer Zertifizierungsstelle, um ein zentrales Inventar zu erstellen. CBOM Secure von Encryption Consulting wurde genau für diesen Zweck entwickelt. Es führt eine kontinuierliche kryptografische Erkennung in Ihrer gesamten Infrastruktur durch und liefert Ihnen so einen vollständigen Überblick über alle kryptografischen Objekte, bevor Sie mit der Automatisierung beginnen. Dies ist der grundlegende Schritt, denn alles Weitere basiert darauf, zu wissen, was sich in Ihrer Umgebung befindet.

Schritt 2: Verlängerungsbenachrichtigungen mit angemessenen Vorlaufzeiten einrichten

Die Alarmschwellenwerte müssen in jeder Phase neu konfiguriert werden. Bei einer Gültigkeitsdauer von 200 Tagen (Phase 1) sollten die Verlängerungsbenachrichtigungen 60 Tage vor Ablauf erfolgen. Bei einer Gültigkeitsdauer von 100 Tagen (Phase 2) sollten die Benachrichtigungen 30 Tage vor Ablauf erfolgen. Bei einer Gültigkeitsdauer von 47 Tagen sollten Benachrichtigungen 25–30 Tage vor Ablauf ausgelöst werden, mit Eskalationswarnungen 14 und 7 Tage vor Ablauf.

Schritt 3: Standardisierung auf ACME für die Zertifikatsausstellung.

ACME (Automated Certificate Management Environment) ist das speziell für die automatisierte Zertifikatsausstellung und -erneuerung entwickelte Protokoll. Der CertSecure Manager von Encryption Consulting unterstützt ACME nativ neben den Protokollen SCEP und EST und ist damit die ideale Plattform für die Standardisierung der automatisierten Zertifikatsausstellung und -erneuerung in jeder Größenordnung. Die direkte Integration mit öffentlichen und privaten Zertifizierungsstellen (CAs) gewährleistet die volle Kompatibilität Ihrer ACME-basierten Erneuerungsprozesse mit der von Ihrem Unternehmen genutzten CA.

Schritt 4: Fest codierte Erneuerungsintervalle eliminieren

Überprüfen Sie alle Skripte, Cronjobs und Automatisierungskonfigurationen, die die Zertifikatserneuerung steuern. Konfigurationen mit einem fest codierten Erneuerungsintervall wie „alle 60 Tage erneuern“ oder „alle 90 Tage erneuern“ funktionieren nicht mehr, da die Gültigkeitsdauer von Zertifikaten immer kürzer wird. Ersetzen Sie diese durch eine dynamische Erneuerungslogik, die auf dem Ablaufdatum des Zertifikats oder ACME-ARI-Signalen basiert.

Schritt 5: Die Lücke zwischen Erneuerung und Bereitstellung schließen.

Prüfen Sie für jedes Zertifikat in Ihrem Bestand, ob der Erneuerungsprozess einen Bereitstellungsschritt und einen Verifizierungsschritt nach der Bereitstellung umfasst, um sicherzustellen, dass das erneuerte Zertifikat tatsächlich an die Clients ausgeliefert wird. Dies ist besonders wichtig in Umgebungen, in denen Erneuerung und Bereitstellung von separaten Systemen oder Teams durchgeführt werden.

Schritt 6: Behebung von Problemen mit der bestehenden Infrastruktur

Identifizieren Sie alle Systeme, die nicht an der automatischen Erneuerung teilnehmen können, darunter ältere Server, in die Firmware eingebettete Zertifikate und festgelegte Konfigurationen. Definieren Sie für jedes dieser Systeme einen Migrationspfad, bevor Phase 2 die Änderung erzwingt. Diese Änderungen sind in der Regel am zeit- und ressourcenintensivsten und müssen deutlich vor dem endgültigen Stichtag begonnen werden.

Schritt 7: Zentralisierte Transparenz und Steuerung schaffen

Wechseln Sie zu einer zentralen Plattform für das Zertifikatslebenszyklusmanagement (CLM) wie unserem CertSecure Manager, die einheitliche Bestandsverwaltung, automatisierte Verlängerung, Bereitstellungssteuerung und Compliance-Berichte für alle Umgebungen bietet. Die operative Komplexität der heutigen 47-Tage-Ära ist mit einer fragmentierten, umgebungsspezifischen Zertifikatsverwaltung nicht vereinbar.

Wie Verschlüsselungsberatung helfen kann

Bei Encryption Consulting haben wir ein Portfolio an Produkten und Dienstleistungen entwickelt, das speziell darauf ausgelegt ist, Unternehmen bei der 47-tägigen Zertifikatsumstellung zu unterstützen – von der automatisierten Lebenszyklusverwaltung und kryptografischen Erkennung bis hin zur vollständig verwalteten PKI und der Post-Quanten-Bereitschaft.

CertSecure Manager ist die dedizierte Zertifikatslebenszyklusmanagement-Plattform von Encryption Consulting und die optimale Lösung für die Anforderungen der 47-Tage-Regelung. Sie automatisiert die Ausstellung, Verlängerung und Bereitstellung von Zertifikaten in großem Umfang mithilfe der Protokolle ACME, SCEP und EST und wurde speziell für häufige Verlängerungszyklen entwickelt, bei denen manuelle Prozesse nicht mehr ausreichen.

Die Plattform automatisiert die Zertifikatsregistrierung und -erneuerung für Webserver wie Apache, Tomcat und IIS sowie für Load Balancer wie F5 BIG-IP. Sie integriert sich mit öffentlich vertrauenswürdigen Zertifizierungsstellen wie DigiCert und Entrust sowie mit privaten vertrauenswürdigen Zertifizierungsstellen wie Microsoft PKI, AWS Private CA und HashiCorp CA. Die Erneuerung wird dynamisch anhand des Zertifikatsablaufs und nicht durch fest codierte Intervalle ausgelöst. Dadurch ist die Plattform von Natur aus mit jeder neuen Phase des SC-081v3-Zeitplans kompatibel.

Die Plattform ist auf Krypto-Agilität ausgelegt und da die finalisierten PQC-Standards des NIST zunehmend Einfluss auf die Anforderungen an Browser und Root-Programme nehmen, unterstützt die Plattform Organisationen bei der Bewertung ihrer aktuellen kryptografischen Lage und ermöglicht die kontrollierte, schrittweise Migration zu quantensicheren Zertifikaten, ohne dass ein Plattformwechsel oder eine störende manuelle Migration erforderlich ist.

Neben unserem CertSecure Manager bieten wir auch PKI-as-a-Service für Unternehmen an, die die deutlich erhöhte Last der Zertifikatsausstellung aufgrund der 47-tägigen Gültigkeitsdauer bewältigen müssen, ohne ihre interne PKI-Infrastruktur aufzubauen oder zu überarbeiten. PKI-as-a-Service stellt eine vollständig verwaltete PKI bereit, die mit der neuen Erneuerungsfrequenz skaliert. Da die Zertifikatsausstellungsraten bis 2029 steigen, werden Unternehmen mit unzureichend ausgestatteter interner CA-Infrastruktur vor Herausforderungen hinsichtlich Durchsatz und Verfügbarkeit stehen. PKI-as-a-Service übernimmt diese Last, ohne dass Änderungen an der internen Infrastruktur erforderlich sind. So kann sich Ihr Team auf Governance und Compliance anstatt auf den CA-Betrieb konzentrieren.

CBOM Secure ist ein weiteres Produkt von Encryption Consulting zur kryptografischen Erkennung und Inventarisierung und unterstützt Sie bei der Umsetzung des 47-Tage-Plans für die Umstellung von TLS-Zertifikaten. Bevor Sie Zertifikate automatisiert verwalten können, müssen Sie genau wissen, welche kryptografischen Assets in Ihrer Umgebung vorhanden sind. CBOM Secure erkennt jedes Zertifikat in Ihrer Infrastruktur, sodass Sie präzise wissen, welche Zertifikate vor jedem Stichtag automatisiert verwaltet werden müssen.

Fazit

Die Entscheidung des CA/Browser Forums, die Gültigkeit von TLS-Zertifikaten bis März 2029 auf 47 Tage zu reduzieren, stellt die bedeutendste Änderung im Zertifikatslebenszyklusmanagement seit über einem Jahrzehnt dar. Phase 1 ist bereits angelaufen, Phase 2 folgt im März 2027. Die 47-Tage-Gültigkeitsdauer im Jahr 2029 rückt somit in puncto Infrastrukturplanung in greifbare Nähe.

Organisationen, die diese Phasen reibungslos verstehen und anwenden, behandeln das Zertifikatslebenszyklusmanagement als automatisierte, überwachte, zentral gesteuerte und kontinuierlich getestete Infrastruktur und nicht als periodische Verwaltungsaufgabe. Organisationen, die erst handeln, wenn eine Phase sie dazu zwingt, werden mit wiederkehrenden Betriebskrisen konfrontiert sein, deren Häufigkeit mit der zunehmenden Verkürzung der Gültigkeitsdauer steigt.

Wir von Encryption Consulting unterstützen Sie bei jedem Schritt dieses Weges. Jetzt ist der richtige Zeitpunkt, diese Infrastruktur aufzubauen, bevor Phase 2 die entstehenden Lücken schmerzhaft und schwer zu beheben macht.