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

Die im April 2025 verabschiedete CA/Browser Forum-Abstimmung SC-081v3 reduziert die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate bis zum 15. März 2029 in drei Phasen von 398 auf 47 Tage. Sollte Ihre Organisation noch manuelle Verlängerungsprozesse, Kalendererinnerungen oder andere manuelle Verfahren zur Überwachung des Zertifikatsablaufs nutzen, ist dies vor Erreichen der letzten Phase nicht mehr wirtschaftlich. Der erste notwendige Schritt ist die Erstellung eines vollständigen Zertifikatsinventars: Was man nicht findet, kann nicht automatisiert werden.

Kurzantwort: Was ist die 47-Tage-TLS-Zertifikatspflicht?

Die CA/Browser Forum-Abstimmung SC-081v3 verkürzt die maximale Gültigkeitsdauer von TLS-Zertifikaten bis zum 15. März 2029 von 398 auf 47 Tage. Die Verkürzung erfolgt in drei Phasen: 200 Tage ab dem 15. März 2026 (bereits in Kraft), 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Die Wiederverwendung der Domain Control Validation (DCV) wird im gleichen Rhythmus reduziert und erreicht 2029 nur noch 10 Tage. Manuelle Verlängerungsprozesse sind mit diesem Zeitplan nicht kompatibel. Eine ACME-basierte Automatisierung ist erforderlich.

Wichtige Erkenntnisse

• Die Abstimmung im CA/Browser Forum SC-081v3 verkürzt die maximale Gültigkeitsdauer von TLS-Zertifikaten in drei Phasen von 398 Tagen auf 47 Tage: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Phase 1 ist bereits in Kraft.
• Die Wiederverwendungszeiträume für die Domain-Control-Validierung (DCV) verkürzen sich im gleichen Rhythmus und erreichen bis 2029 nur noch 10 Tage. Dadurch wird die ACME-basierte automatisierte Domain-Validierung zu einer zwingenden betrieblichen Voraussetzung und nicht zu einer Optimierung.
• 72 % der Unternehmen verzeichneten in den letzten zwölf Monaten mindestens einen Zertifikatsausfall, und nur 34 % verfügen über einen vollständigen und aktuellen Überblick über ihre eigenen Zertifikate. Der 47-Tage-Zyklus verkürzt diese Arbeitslast um das Sechsfache.
• Manuelle Verlängerungen und Kalendererinnerungen sind für 47-Tage-Zertifikate nicht praktikabel. ACME-basierte Automatisierung, Überprüfung der Bereitstellung und ein zentrales Zertifikatsinventar sind daher mittlerweile Standardvoraussetzungen.
• Certificate Pinning ist grundsätzlich unvereinbar mit einer Gültigkeitsdauer von 47 Tagen. Umgebungen, die Pinning verwenden, müssen bis März 2029 auf die standardmäßige CA-basierte Vertrauensprüfung umgestellt werden.
• Die Lücke zwischen Zertifikatserneuerung und -bereitstellung, bei der ein erneuertes Zertifikat zwar erhalten, aber nicht bereitgestellt wird, stellt bei einer Gültigkeitsdauer von 47 Tagen einen kritischen Fehler dar. Die Automatisierung muss eine Überprüfung nach der Bereitstellung umfassen.

Was hat die Wahl SC-081v3 geändert und wann tritt jede Phase in Kraft?

Der von Apple im Januar 2025 vorgeschlagene Wahlvorschlag SC-081v3 wurde am 11. April 2025 vom CA/Browser Forum mit 25 Ja-Stimmen und keiner Nein-Stimme angenommen. Alle vier großen Browserhersteller – Apple, Google, Microsoft und Mozilla – stimmten dafür. Die Frist für die Überprüfung der IP-Rechte endete am 13. Mai 2025 ohne Einwände, wodurch der Wahlvorschlag ab diesem Datum rechtskräftig wurde.

Die Abstimmung ändert zwei Abschnitte der TLS-Basisanforderungen des CA/Browser-Forums:

• 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 fest, um die Zeitspanne zu verkürzen, in der DCV-Nachweise (Domain Control Validation) zwischen Zertifikatsausstellungen wiederverwendet werden können.

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

Phase	Datum des Inkrafttretens	Maximale Gültigkeitsdauer des TLS-Zertifikats	Maximale Wiederverwendungsdauer von DCV	Aktueller Status
Phase 1	15. März 2026	200 Tage	200 Tage	Tritt in Kraft. Jedes neue TLS-Zertifikat, das an oder nach diesem Datum ausgestellt wird, hat eine maximale Gültigkeitsdauer von 200 Tagen.
Phase 2	15. März 2027	100 Tage	100 Tage	Demnächst. Die Erneuerungshäufigkeit verdoppelt sich im Vergleich zu Phase 1.
Phase 3	15. März 2029	47 Tage	10 Tage	Demnächst. Zertifikate werden etwa alle 6 Wochen erneuert. Die DCV-Zertifizierung muss bei fast jeder Verlängerung erneut überprüft werden.

Die Domainkontrollvalidierung (DCV) ist das Verfahren, mit dem eine Zertifizierungsstelle überprüft, ob ein Zertifikatsantragsteller die beantragte Domain kontrolliert. Bisher konnten diese Validierungsnachweise bis zu 398 Tage lang wiederverwendet werden. SC-081v3 verkürzt dieses Wiederverwendungsfenster bis März 2029 auf nur noch 10 Tage. Das bedeutet, dass die Domaininhaberschaft bei nahezu jeder Zertifikatserneuerung erneut überprüft werden muss. Eine detaillierte Anleitung zur Automatisierung der DCV finden Sie in unserem Leitfaden zu persistenter DCV und DNS-Konnektoren.

Warum hat das CA/Browser-Forum diese Entscheidung getroffen?

Die Tendenz zu kürzeren Zertifikatsgültigkeitsdauern zeichnet sich seit über einem Jahrzehnt ab. TLS-Zertifikate waren bis 2015 bis zu fünf Jahre gültig. Die maximale Gültigkeitsdauer sank 2015 auf drei Jahre, 2018 auf zwei Jahre und 2020 auf 398 Tage, als Apple die Vertrauenswürdigkeit neuer Zertifikate in Safari einseitig begrenzte. SC-081v3 setzt diese Entwicklung mit einem festen Endpunkt fort. Das CA/Browser Forum nannte vier Gründe für diese Änderung:

• Begrenzung des Wirkungsradius kompromittierter Zertifikate: Wird ein privater Schlüssel gestohlen, ein Zertifikat gefälscht ausgestellt oder ein Signaturalgorithmus als schwach erkannt, ist der Schaden direkt proportional zur Gültigkeitsdauer des Zertifikats. Ein 47-Tage-Zertifikat bietet ein deutlich kürzeres Zeitfenster für Missbrauch als ein 398-Tage-Zertifikat.
• Die Wirksamkeit des Widerrufs sicherstellen: Die Zertifikatssperrung funktioniert in der Praxis weitgehend nicht. Das Online Certificate Status Protocol (OCSP) arbeitet in den meisten Browsern mit einem Soft-Fail-Prinzip, d. h., wenn der OCSP-Responder nicht erreichbar ist, wird die Verbindung vom Browser fortgesetzt, anstatt sie zu blockieren. Zertifikatssperrlisten (CRLsDie Aktualisierungen und Überprüfungen erfolgen nur selten und uneinheitlich. Let's Encrypt hat OCSP im Jahr 2024 vollständig abgeschafft und den Übergang im Jahr 2025 abgeschlossen. Bei einer Gültigkeitsdauer von 47 Tagen ist das natürliche Ablaufdatum der primäre Widerrufsmechanismus.
• Durchsetzung strengerer kryptografischer Verfahren: Langlebige Zertifikate ermöglichen es Organisationen, Algorithmusmigrationen hinauszuzögern. Ein Zertifikat, das 2023 mit einer geringen Schlüssellänge oder einem veralteten Algorithmus ausgestellt wurde, kann mit einer Gültigkeit von 398 Tagen bis 2025 im Produktivbetrieb bleiben. Kürzere Gültigkeitsdauern erfordern eine häufigere Ausstellung und Anwendung aktueller Algorithmus- und Schlüsselstandards.
• Förderung der Automatisierungsakzeptanz: Das CA/Browser Forum stellte ausdrücklich fest, dass eines der Ziele von SC-081v3 die erzwungene Einführung eines automatisierten Zertifikatslebenszyklusmanagements ist. Ein 47-Tage-Zertifikat, das alle sechs Wochen erneuert wird, ist mit manuellen Prozessen betrieblich nicht vereinbar, weshalb die Automatisierung eher eine strukturelle Notwendigkeit als eine Best Practice darstellt.

Was sagen die Daten über den aktuellen Reifegrad des Zertifikatsmanagements aus?

Die durch SC-081v3 verursachten Störungen sind nicht hypothetisch. Branchenuntersuchungen zeigen, dass das Umfeld bei einer Gültigkeitsdauer von 398 Tagen bereits stark beansprucht ist:

• Laut dem Bericht „State of Machine Identity Security 2025“ gaben 72 % der Unternehmen an, in den letzten zwölf Monaten mindestens einen Ausfall im Zusammenhang mit Zertifikaten erlebt zu haben, und 45 % berichteten, dass es wöchentlich zu Ausfällen komme. Im Jahr 2022 hatten lediglich 12 % der Unternehmen wöchentliche Ausfälle gemeldet.
• Laut einer globalen Umfrage unter mehr als 400 leitenden IT- und Sicherheitsexperten aus dem Jahr 2026 verfügen nur 34 % der Unternehmen über einen vollständigen und aktuellen Überblick über ihre eigenen digitalen Zertifikate, und fast drei Viertel sind sehr oder extrem besorgt über Ausfälle, die durch abgelaufene Zertifikate verursacht werden.
• Maschinenidentitäten übertreffen menschliche Identitäten mittlerweile schätzungsweise um das 82-Fache, und 79 % der Sicherheitsverantwortlichen gehen davon aus, dass dieses Verhältnis im nächsten Jahr um bis zu 150 % weiter steigen wird.

Diese Zahlen beschreiben eine Branche, die bereits bei jährlichen Erneuerungszyklen an ihre Grenzen stieß. Die gleiche Arbeitslast in 47-Tage-Zyklen zu komprimieren, mit einem 10-tägigen Zeitfenster für die Wiederverwendung von DCVs, das bei nahezu jeder Erneuerung eine erneute Domänenverifizierung erfordert, ist mit manuellen Prozessen nicht zu bewältigen. Weitere Informationen darüber, wie das Wachstum der Maschinenidentitäten dieses Problem für PKI-Teams verschärft, finden Sie in unserem Leitfaden zur Maschinenidentität für PKI-Teams.

Was bedeuten 47-Tage-Zertifikate in der Praxis?

Die betrieblichen Auswirkungen von SC-081v3 variieren je nach Größe und Komplexität des Zertifikatsbestands und dem aktuellen Stand der Zertifikatsverwaltungspraktiken. Drei Bereiche bergen die größten und beständigsten betrieblichen Herausforderungen:

Transparenz des Zertifikatsbestands

Die Erneuerung von Zertifikaten, deren Existenz Ihnen unbekannt ist, lässt sich nicht automatisieren. Eine unübersichtliche Zertifikatslandschaft, die sich über mehrere Teams, Cloud-Umgebungen, Kubernetes- Cluster, CDN-Konfigurationen und Legacy-Server erstreckt, 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 erfasstes Zertifikat innerhalb weniger Wochen nach der Ausstellung ab. Die Schaffung umfassender Transparenz über alle Zertifikatsbestände hinweg – einschließlich interner Dienste, nicht kundenorientierter Infrastruktur und von externen Teams verwalteter Zertifikate – ist die grundlegende Voraussetzung für alles Weitere.

Die Lücke zwischen Erneuerung und Einsatz

Einer der häufigsten Fehler in automatisierten Zertifikatsumgebungen ist die Lücke zwischen Zertifikatserneuerung und -bereitstellung: Der ACME-Client erhält zwar erfolgreich ein neues Zertifikat, doch die Installation auf dem entsprechenden Server, Load Balancer oder Kubernetes-Ingress schlägt unbemerkt fehl. Das erneuerte Zertifikat bleibt ungenutzt, während das alte Zertifikat weiterhin Datenverkehr verarbeitet, bis es abläuft. Bei einer Gültigkeitsdauer von 47 Tagen stellt diese Lücke einen kritischen Fehler dar. Die Zertifikatserneuerung muss daher in die Bereitstellungsprüfung integriert werden, um sicherzustellen, dass das neue Zertifikat tatsächlich an die Clients ausgeliefert wird, bevor die Erneuerung als abgeschlossen markiert wird.

Legacy-Infrastruktur und Zertifikats-Pinning

Legacy-Anwendungen mit fest codierten Zertifikaten, IoT-Geräte mit in die Firmware integrierten Zertifizierungsstellen und Umgebungen mit Certificate Pinning stellen allesamt Fälle dar, in denen 47-Tage-Zertifikate Herausforderungen mit sich bringen, die sich allein durch Automatisierung nicht lösen lassen. Certificate Pinning, bei dem ein Client so konfiguriert ist, dass er nur einem bestimmten Zertifikat oder öffentlichen Schlüssel vertraut, anstatt jedem Zertifikat einer vertrauenswürdigen Zertifizierungsstelle, ist grundsätzlich unvereinbar mit einer Gültigkeit von 47 Tagen. Der einzig praktikable Ansatz für Umgebungen mit Certificate Pinning ist die Migration von Pinning hin zur standardmäßigen, CA-basierten Vertrauensprüfung bis März 2029.

Manuelles vs. automatisiertes Zertifikatsmanagement: Welcher Ansatz überlebt 47 Tage?

Der folgende Vergleich zeigt, warum manuelle Prozesse vor Phase 3 nicht mehr praktikabel sind:

Anforderung bei einer Gültigkeitsdauer von 47 Tagen	Manuell oder kalendergesteuert	Automatisiertes CLM (ACME + CertSecure Manager)
Verlängerungen pro Zertifikat pro Jahr	1 heute, ansteigend auf 8 oder mehr bis März 2029	Gleiches Volumen, keine zusätzliche Personenzahl
Domänenvalidierung (10-tägige DCV-Wiederverwendung bis 2029)	Bei jedem Erneuerungszyklus manuell erneut ausführen	Maschinell-zu-Maschine-Challenge-Response über ACME-Protokolle (HTTP-01, DNS-01)
Zertifikatsinventar	Tabellenkalkulationen, Stammeswissen und manuelle Scans	Kontinuierliche Erkennung über Cloud-, On-Premises- und Kubernetes-Umgebungen hinweg
Lücke zwischen Erneuerung und Einsatz	Üblicherweise können erneuerte Zertifikate ungenutzt bleiben, während alte ablaufen.	Die Bereitstellung wurde automatisch überprüft, bevor die Verlängerung als abgeschlossen markiert wurde.
Ausfallrisiko	Hoch, im Einklang mit der oben genannten branchenweiten Ausfallrate von 72 %.	Niedriger; die Verlängerung wird durch das Ablaufdatum ausgelöst, nicht durch eine Kalendererinnerung.
Audit- und Compliance-Berichte	Manuelle Protokollabfragen; uneinheitliche Abdeckung in verschiedenen Umgebungen	Zentralisierte, exportierbare Verlängerungs- und Ausstellungshistorie über alle Umgebungen hinweg
DCV-Automatisierung	Manuelle Herausforderung abschließen; Unterbrechungen nach 10 Tagen Wiederverwendungsfenster	ACME automatisiert den Abschluss von Herausforderungen; DNS-Konnektoren ermöglichen dauerhaftes DCV

Wie sollten sich Organisationen auf den 47-tägigen Zertifizierungsplan vorbereiten?

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 erforderlichen Infrastruktur begrenzt. Die folgende siebenstufige Abfolge verdeutlicht die Reihenfolge, in der die Abhängigkeiten aufgelöst werden müssen:

1. Erstellen Sie ein vollständiges Zertifikatsinventar: Entdecken Sie alle öffentlichen TLS-Zertifikate in allen Umgebungen und Teams. Nutzen Sie die Protokollüberwachung mittels Certificate Transparency (CT), APIs von Cloud-Anbietern, Netzwerkscans und Integrationen mit der Verwaltungskonsole Ihrer Zertifizierungsstelle. CBOM Secure Es führt eine kontinuierliche kryptografische Erkennung in Cloud-, On-Premises- und Kubernetes-Umgebungen durch und liefert Ihnen so einen vollständigen Überblick über alle Zertifikate, bevor Sie mit der Automatisierung beginnen. Dies ist der grundlegende Schritt: Alles Weitere basiert auf der Kenntnis Ihrer vorhandenen Zertifikate. Als Nachweis dient ein vollständiges Zertifikatsinventar mit Zertifizierungsstelle (CA), Ablaufdatum, Installationsort und Inhaber für jedes Zertifikat.
2. Erneuerungsbenachrichtigungen mit phasengerechten Vorlaufzeiten einrichten: Bei einer Gültigkeitsdauer von 200 Tagen (Phase 1) werden Verlängerungsbenachrichtigungen 60 Tage vor Ablauf eingerichtet. Bei einer Gültigkeitsdauer von 100 Tagen (Phase 2) erfolgen die Benachrichtigungen 30 Tage vor Ablauf. Bei einer Gültigkeitsdauer von 47 Tagen (Phase 3) werden Benachrichtigungen 25 bis 30 Tage vor Ablauf ausgelöst, mit Eskalationswarnungen 14 und 7 Tage vor Ablauf. Als Nachweis dient die Konfiguration der Benachrichtigungen auf der CLM-Plattform mit den Schwellenwerten pro Umgebung und Phase.
3. Standardisierung der Zertifikatsausstellung auf ACME: Das Automated Certificate Management Environment (ACME)-Protokoll (RFC 8555) ist der speziell für die automatisierte Ausstellung und Erneuerung von Zertifikaten entwickelte Mechanismus. CertSecure Manager Unterstützt ACME nativ neben den Protokollen SCEP und EST und integriert sich direkt in öffentliche und private Zertifizierungsstellen. Nachweis: Bereitstellungsdatensätze des ACME-Clients; Protokolle über erfolgreiche automatische Verlängerungen, die den Abschluss der Domänenvalidierung belegen.
4. Fest codierte Erneuerungsintervalle eliminieren: Prüfen Sie alle Skripte, Cronjobs und Automatisierungskonfigurationen auf fest codierte Erneuerungsintervalle wie „alle 60 Tage erneuern“ oder „alle 90 Tage erneuern“. Ersetzen Sie diese durch eine dynamische Erneuerungslogik, die auf dem Ablaufdatum des Zertifikats oder ACME ARI-Signalen (Automatic Renewal Information) basiert. Nachweis: Ergebnisse der Konfigurationsprüfung; aktualisierte Automatisierung mit ablaufbasierter Erneuerungslogik.
5. Schließen Sie die Lücke zwischen Erneuerung und Bereitstellung: Prüfen Sie für jedes Zertifikat im Geltungsbereich, ob der Erneuerungsprozess einen Bereitstellungsschritt und einen Nachbereitungs-Verifizierungsschritt umfasst, der bestätigt, 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 verwaltet werden. Als Nachweis dienen Bereitstellungs-Verifizierungsprotokolle, die belegen, dass das ausgelieferte Zertifikat bei jedem Erneuerungsereignis mit dem erneuerten Zertifikat übereinstimmt.
6. Umgang mit veralteter Infrastruktur und Zertifikatsbindung: Identifizieren Sie alle Systeme, die nicht an der automatischen Erneuerung teilnehmen können: Legacy-Server, in die Firmware eingebettete Zertifikate und fixierte Konfigurationen. Definieren Sie für jedes dieser Systeme einen Migrationspfad vor Phase 3. Diese Änderungen sind in der Regel am zeitaufwändigsten und müssen deutlich vor März 2029 beginnen. Erforderliche Nachweise: Inventar der Legacy-Infrastruktur; Migrationsplan mit Verantwortlichem und Zieldatum für jedes System; Aufzeichnungen zur Aufhebung der Zertifikatfixierung.
7. Zentralisierte CLM-Governance einführen: Wechseln Sie zu einer zentralen Plattform für das Zertifikatslebenszyklusmanagement (CLM), die einheitliche Bestandsverwaltung, automatisierte Verlängerung, orchestrierte Bereitstellung und Compliance-Berichte für alle Umgebungen bietet. Die operative Komplexität der 47-Tage-Frist ist mit einer fragmentierten, umgebungsspezifischen Zertifikatsverwaltung nicht vereinbar. Nachweis: Bereitstellung der CLM-Plattform für alle relevanten Umgebungen; Compliance-Bericht mit null Zertifikaten innerhalb der nächsten 7 Tage.

TLS-Checkliste für die 47-tägige Bereitschaftsprüfung

Nutzen Sie diese Checkliste, um die Bereitschaft Ihrer Organisation für jede Phase von SC-081v3 zu bewerten. Die Punkte sind danach geordnet, in welcher Phase sie kritisch werden:

Kontrollbereich	Anforderung	Kritisch von	Beweisstück	Status
Zertifikatsinventar	Vollständiges Verzeichnis aller öffentlichen TLS-Zertifikate mit Zertifizierungsstelle, Ablaufdatum, Installationsort und zuständigem Team	Jetzt (Phase 1 in Kraft)	CLM-Inventarexport oder CBOM Secure Discovery-Bericht	Zum Handeln
Phase-1-Konformität	Alle neuen TLS-Zertifikate, die am oder nach dem 15. März 2026 ausgestellt werden, haben eine maximale Gültigkeitsdauer von 200 Tagen.	15. März 2026 (bereits in Kraft)	Konfiguration der CA-Ausstellungsrichtlinie; Zertifikatsprüfung, die bestätigt, dass keine neuen Zertifikate länger als 200 Tage gültig sind.	Zum Handeln
ACME-Automatisierungsbereitstellung	Die auf ACME basierende automatische Erneuerung wurde für alle öffentlichen TLS-Zertifikate eingeführt.	Vor Phase 2 (März 2027)	ACME-Client-Bereitstellungsprotokolle; Protokolle erfolgreicher automatisierter Verlängerungen	Zum Handeln
DCV-Automatisierung	Automatisierte Domänenkontrollvalidierung, die HTTP-01- oder DNS-01-Herausforderungen ohne manuelle Intervention bewältigen kann	Vor Phase 2 (März 2027); kritisch ab Phase 3 (10-tägiges Wiederverwendungsfenster)	ACME-Challenge-Abschlussprotokolle; DNS-Connector-Konfiguration	Zum Handeln
Schwellenwerte für die Erneuerungsbenachrichtigung	Die pro Phase konfigurierten Alarmschwellenwerte sind: 60 Tage für Phase 1, 30 Tage für Phase 2, 25 bis 30 Tage für Phase 3.	Laufend; Aktualisierung in jeder Phase	CLM-Plattform-Alarmkonfiguration; Nachweis der Alarmzustellung	Zum Handeln
Prüfung des fest codierten Erneuerungsintervalls	Weder Automatisierungsskripte noch Cronjobs verwenden fest codierte Erneuerungsintervalle; alle nutzen ablaufbasierte oder ACME-ARI-Logik.	Vor Phase 2 (März 2027)	Ergebnisse der Konfigurationsprüfung; aktualisierte Skripte mit dynamischer Erneuerungslogik	Zum Handeln
Schließung der Lücke zwischen Erneuerung und Einsatz	Die Automatisierung der Zertifikatserneuerung umfasst die Überprüfung nach der Bereitstellung, um zu bestätigen, dass das neue Zertifikat an die Clients ausgeliefert wurde.	Vor Phase 2 (März 2027)	Bereitstellungsprüfungsprotokolle pro Erneuerungsereignis	Zum Handeln
Phase-2-Konformität	Alle neuen TLS-Zertifikate, die am oder nach dem 15. März 2027 ausgestellt werden, haben eine maximale Gültigkeitsdauer von 100 Tagen.	15. März 2027	Konfiguration der CA-Ausstellungsrichtlinie; Zertifikatsprüfung zur Bestätigung der Konformität	Zum Handeln
Migration bestehender Infrastrukturen	Für alle Systeme, die manuelle Zertifikatsbereitstellung, fest codierte Zertifikate oder in die Firmware eingebettete Zertifizierungsstellen verwenden, liegt ein dokumentierter Migrationsplan mit einem Zieldatum vor März 2029 vor.	Vor Phase 3 (März 2029)	Bestandsaufnahme der bestehenden Infrastruktur; Migrationsplan mit Verantwortlichem und Zieldatum	Zum Handeln
Entfernung der Zertifikatsbindung	In Produktionssystemen wird kein Zertifikats- oder Public-Key-Pinning für öffentlich vertrauenswürdige Zertifikate verwendet.	Vor Phase 3 (März 2029)	Anwendungscodeprüfung; Protokolle zur Aufhebung von Sperren; Bestätigung der standardmäßigen, CA-basierten Vertrauensprüfung	Zum Handeln
Phase-3-Konformität	Alle neuen TLS-Zertifikate, die am oder nach dem 15. März 2029 ausgestellt werden, haben eine maximale Gültigkeitsdauer von 47 Tagen; die Wiederverwendung von DCVs ist auf 10 Tage begrenzt.	15. März 2029	Richtlinien zur Zertifizierungsstellenausstellung; DCV-Automatisierungsprotokolle; Zertifikatsprüfung zur Bestätigung der Konformität	Zum Handeln
Zentrale Steuerung von CLM	Die zentrale CLM-Plattform bietet einheitliche Bestandsverwaltung, Automatisierung der Vertragserneuerung, Bereitstellungssteuerung und Compliance-Berichte für alle Umgebungen.	Vor Phase 3 (März 2029)	CLM-Plattformabdeckungsbericht; Compliance-Bericht mit dem Hinweis, dass innerhalb von 7 Tagen nach Ablauf keine Zertifikate mehr vorliegen	Zum Handeln
Krypto-Agilität für Authentifizierungssysteme	Die CLM-Plattform unterstützt die Ausstellung von Post-Quantum-Zertifikaten für zukünftige Migrationen, sobald die NIST-PQC-Standards von Browser-Root-Programmen übernommen werden.	Planung jetzt; Umsetzung 2028 bis 2030	PQC-Roadmap des Anbieters; PQC-Supportdokumentation der CLM-Plattform	Zum Handeln

Wie Verschlüsselungsberatung beim 47-tägigen Übergang helfen kann

Encryption Consulting ist ein nach ISO/IEC 27001:2022 und SOC 2 zertifiziertes Unternehmen für angewandte Kryptografie. Unser Portfolio deckt alle Komponenten des 47-tägigen Übergangs ab: automatisiertes Lebenszyklusmanagement, kryptografische Erkennung, vollständig verwaltete PKI und Post-Quanten-Bereitschaft.

• CertSecure Manager: CertSecure Manager ist die Zertifikatslebenszyklusmanagement-Plattform von Encryption Consulting und die direkteste operative Antwort auf 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. Die Plattform automatisiert die Registrierung und Verlängerung auf Webservern wie Apache, Tomcat und IIS sowie auf Load Balancern wie F5 BIG-IP. Verlängerungen werden dynamisch anhand der Ablaufdaten der Zertifikate ausgelöst, nicht durch fest codierte Intervalle. Dadurch ist die Plattform mit jeder Phase von SC-081v3 kompatibel. Sie ist auf Kryptoagilität ausgelegt und ermöglicht Unternehmen eine kontrollierte, schrittweise Migration zu Post-Quantum-Zertifikaten, sobald die NIST-PQC-Standards von Browser-Root-Programmen übernommen werden. Weitere Informationen finden Sie in unserer Migrationsleitfaden für Post-Quanten-Kryptographie für den vollständigen neunphasigen Migrationsrahmen.
• CBOM Secure (Kryptografisches Inventar): CBOM Secure Es erkennt jedes Zertifikat in Ihrer gesamten Infrastruktur, einschließlich Cloud-Konten, lokalen Umgebungen und Kubernetes-Clustern, sodass Sie genau wissen, was vor jedem Stichtag automatisiert verwaltet werden muss. Dies ist der grundlegende Schritt in der siebenstufigen Vorbereitungssequenz: Was man nicht findet, kann man nicht automatisieren. Siehe auch unseren Leitfaden zu Der kryptografische blinde Fleck in Ihrer eigenen Infrastruktur warum den meisten Inventarlisten wichtige Zertifikate fehlen.
• PKI als Dienstleistung: Für Organisationen, die die deutlich erhöhte Last der Zertifikatsausstellung mit einer Gültigkeitsdauer von 47 Tagen bewältigen müssen, ohne ihre interne PKI-Infrastruktur grundlegend zu überarbeiten, PKI-as-a-Service bietet eine vollständig verwaltete Zertifizierungsstelle (CA), die für die Skalierung mit der neuen Erneuerungsfrequenz ausgelegt ist. Da sich die Ausstellungsraten bis 2029 versechsfachen, werden Organisationen 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.
• Permanente DCV- und DNS-Konnektoren: Für Organisationen, die den Schritt der Domänenvalidierung selbst automatisieren müssen, bietet unser persistenter DCV- und DNS-Connector Der Leitfaden behandelt die ACME-Herausforderung der Automatisierung für das 10-tägige DCV-Wiederverwendungsfenster, das in Phase 3 ansteht.

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 beginnt im März 2027. Die 47-Tage-Frist im März 2029 ist ein verbindlicher Stichtag, der von den Browsern strikt eingehalten werden muss.

Organisationen, die jede Phase reibungslos bewältigen, behandeln das Zertifikatslebenszyklusmanagement als automatisierte, überwachte, zentral gesteuerte und kontinuierlich getestete Infrastruktur und nicht als periodische Verwaltungsaufgabe. Organisationen, die erst in jeder Phase handeln, wenn Handlungsbedarf besteht, werden aufgrund der immer kürzer werdenden Gültigkeitsdauern zunehmend mit wiederkehrenden Betriebskrisen konfrontiert sein.

Häufig gestellte Fragen

Was besagt die 47-Tage-Gültigkeitsregel des CA/Browser-Forums für Zertifikate?

Der im April 2025 verabschiedete Gesetzesentwurf SC-081v3 reduziert die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate bis zum 15. März 2029 von 398 auf 47 Tage. Die Reduzierung erfolgt in drei Phasen: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Alle großen Browserhersteller, darunter Apple, Google, Microsoft und Mozilla, stimmten dafür. Phase 1 ist bereits in Kraft.

Müssen Zertifikate, die vor dem Ablauf einer Phase ausgestellt wurden, vorzeitig ersetzt werden?

Nein. Ein vor dem Inkrafttreten einer Phase ausgestelltes Zertifikat behält seine ursprüngliche Gültigkeitsdauer bis zu seinem regulären Ablauf. Die neue Höchstgültigkeitsdauer gilt nur für Zertifikate, die am oder nach dem jeweiligen Stichtag ausgestellt oder verlängert werden. Es gibt keine Übergangsfrist: Jedes Zertifikat, das am oder nach dem 15. März 2026 ausgestellt wird, muss die für diese Phase geltende Höchstgültigkeitsdauer von 200 Tagen einhalten.

Was ist die Wiederverwendung der Domänenkontrollvalidierung (DCV) und warum ist sie wichtig?

Die Wiederverwendung von Domain-Validierungen (DCV) legt fest, wie lange eine Zertifizierungsstelle sich auf eine vorherige Überprüfung des Domaininhabers verlassen kann, bevor sie einen neuen Nachweis anfordert. SC-081v3 verkürzt diesen Zeitraum bis März 2029 auf 10 Tage, was bedeutet, dass der Domaininhaber bei nahezu jeder Zertifikatserneuerung erneut überprüft werden muss. Dadurch wird die ACME-basierte automatisierte Domainvalidierung zu einer zwingenden betrieblichen Anforderung und nicht mehr zu einer Komfortfunktion.

Gilt die 47-Tage-Regel auch für interne oder private Zertifikate?

Nein. SC-081v3 regelt ausschließlich öffentlich vertrauenswürdige TLS-Zertifikate, die von Zertifizierungsstellen in Browser-Root-Programmen ausgestellt werden. Private oder interne PKI unterliegen nicht den Baseline Requirements des CA/Browser Forums und können weiterhin längere Gültigkeitsdauern nutzen. Viele Organisationen passen ihre internen Richtlinien aus Gründen der Konsistenz und zur Vereinfachung der CLM-Automatisierung an den öffentlichen Zeitplan an.

Was ist Certificate Pinning und warum ist es mit 47-Tage-Zertifikaten inkompatibel?

Certificate Pinning bindet ein bestimmtes Zertifikat oder einen öffentlichen Schlüssel fest in eine Client-Anwendung oder ein Gerät ein. Bei einem Erneuerungszyklus von 47 Tagen muss der Client zudem alle sechs Wochen aktualisiert werden, was aus betrieblicher Sicht nicht praktikabel ist. Die einzig praktikable Lösung besteht darin, bis März 2029 von Certificate Pinning auf die standardmäßige, CA-basierte Vertrauensprüfung umzusteigen.

Was ist die Lücke zwischen Erneuerung und Implementierung und wie können Unternehmen sie schließen?

Die Lücke zwischen Zertifikatserneuerung und -bereitstellung entsteht, wenn ein neues Zertifikat zwar ausgestellt, aber nicht bereitgestellt wird. Dadurch wird der Datenverkehr weiterhin mit dem alten Zertifikat abgewickelt, bis dieses abläuft. Bei einer Gültigkeitsdauer von 47 Tagen stellt dies einen kritischen Fehler dar. Um diesen zu beheben, muss die Automatisierung der Zertifikatserneuerung einen Überprüfungsschritt nach der Bereitstellung beinhalten, der bestätigt, dass das neue Zertifikat tatsächlich verwendet wird, bevor die Erneuerung als abgeschlossen markiert wird.

Wie sollten sich Organisationen auf 47-Tage-TLS-Zertifikate vorbereiten?

Die siebenstufige Vorgehensweise ist wie folgt: (1) Erstellung eines vollständigen Zertifikatsinventars; (2) Festlegung phasengerechter Schwellenwerte für Benachrichtigungen bei Zertifikatserneuerungen; (3) Standardisierung der ACME-Automatisierung; (4) Abschaffung fest codierter Erneuerungsintervalle; (5) Schließung der Lücke zwischen Erneuerung und Bereitstellung; (6) Behebung von Problemen mit veralteter Infrastruktur und Certificate Pinning; und (7) Einrichtung einer zentralen CLM-Governance. Beginnen Sie mit der Inventarisierung, da jeder weitere Schritt die Kenntnis Ihrer vorhandenen Zertifikate voraussetzt.