CA/Browser Forum (Forum der Browserhersteller und Zertifizierungsstellen) hat offiziell eine radikale Verkürzung der maximalen Gültigkeitsdauer öffentlicher SSL/TLS-Zertifikate auf lediglich 47 Tage beschlossen. Diese Entscheidung bedeutet eine weltweite Richtlinienänderung für alle großen Zertifikatanbieter – von kommerziellen Zertifizierungsstellen wie DigiCert, Sectigo, Entrust oder GlobalSign bis hin zu Non-Profit-Organisationen wie Let’s Encrypt. Die Initiative zur Verkürzung der Zertifikatsgültigkeit wurde von Apple angestoßen und fand Unterstützung sowohl bei anderen Browseranbietern (Google Chrome, Mozilla) als auch bei den Zertifikatausstellern selbst (u. a. Sectigo). Die Abstimmung, die am 11. April 2025 abgeschlossen wurde, nahm diesen Vorschlag an und läutet ein neues Kapitel im Vertrauensmanagement des Internets ein. In den kommenden Jahren wird die maximale Laufzeit von Zertifikaten schrittweise reduziert, um im März 2029 das Ziel von 47 Tagen zu erreichen. In diesem Artikel beleuchten wir die Gründe für diese Änderung, ihren Umfang sowie die Auswirkungen auf IT-Infrastruktur, DevOps-Praktiken, Zertifikatsverwaltung in Unternehmen und die Endnutzererfahrung. Außerdem stellen wir die Herausforderungen und Chancen vor, die das Zeitalter ultrakurzer Zertifikate mit sich bringt.
Inhaltsverzeichnis
Die Begrenzung auf maximal 47 Tage ist der Höhepunkt eines jahrelangen Trends zur Verkürzung der Lebensdauer von TLS-Zertifikaten. Vor rund einem Jahrzehnt waren Zertifikate üblicherweise noch bis zu 5 Jahre gültig, was später auf 3 Jahre, dann auf 2 Jahre und schließlich auf rund 13 Monate (398 Tage) reduziert wurde. Ein Meilenstein war die Entscheidung Apples im Jahr 2020, die in seinem Ökosystem einseitig eine maximale Gültigkeit öffentlicher Zertifikate von 398 Tagen durchsetzte. Daraufhin begann die Branche, noch kürzere Laufzeiten zu erwägen – Anfang 2022 wurde die Gültigkeit von S/MIME-Zertifikaten verkürzt, und im März 2023 stellte Google die Initiative „Moving Forward, Together“ vor, die 90-tägige Zertifikate empfahl. Man argumentierte, dass eine häufigere Domain-Überprüfung die Domaininhaber besser schütze, indem das Risiko sinke, dass auf veraltete oder ungültige Informationen vertraut werde, was zu fehlerhaften Zertifikatsausstellungen führen könnte.
Nach einem Jahr Debatten im CA/Browser Forum ging Apple noch einen Schritt weiter und reichte einen formellen Antrag ein, die Gültigkeit schrittweise auf 47 Tage zu reduzieren. Im April 2025 erhielt Apples Vorschlag die Unterstützung sowohl der Browserhersteller als auch der größten Zertifizierungsstellen (Google, Mozilla, Sectigo u. a.). Bemerkenswert ist, dass Google, das ursprünglich einen 90-Tage-Limit befürwortete, während der Abstimmung sofort den 47-Tage-Vorschlag Apples unterstützte. Mit der endgültigen Verabschiedung dieser Regelung wird automatisches Zertifikatsmanagement zur Notwendigkeit (wie im Antrag betont: „Durch die fortwährende Verkürzung der Laufzeiten hat das Forum klargemacht, dass Automatisierung im Grunde verpflichtend für ein wirksames Lifecycle-Management ist“). Nachfolgend der Zeitplan zur Umsetzung der Änderung:
Zeitplan zur Verkürzung der maximalen TLS-Gültigkeit (beschlossen im CA/Browser Forum):
Diese Änderungen betreffen alle öffentlich vertrauenswürdigen SSL/TLS-Zertifikate, die von Websites verwendet werden. Gleichzeitig werden die zulässigen Fristen für die Wiederverwendung von Domain-Validierungsergebnissen durch CAs parallel von derzeit 398 Tagen auf 10 Tage im Jahr 2029 verkürzt. Das bedeutet, dass Zertifizierungsstellen deutlich häufiger überprüfen müssen, ob der Antragsteller die Domain weiterhin kontrolliert (selbst bei automatischer Erneuerung). Für OV-/EV-Zertifikate wurde zudem die Frist für die Validierung von Unternehmensdaten (Subject Identity Information) von 825 Tagen auf 398 Tage begrenzt – das heißt, dass Organisationen für EV/OV-Zertifikate jährlich verifiziert werden. Zusammengefasst werden bis 2029 sowohl die Zertifikate selbst als auch die für ihre Ausstellung verwendeten Informationen nahezu monatlich erneuert.
Der Hauptgrund für die drastische Verkürzung der Zertifikatslaufzeit ist der Wunsch, die Sicherheit und Integrität des auf Zertifikaten basierenden Vertrauensmechanismus zu verbessern. Je länger ein Zertifikat gültig ist, desto größer ist das Risiko, dass die darin enthaltenen Informationen nicht mehr aktuell oder weniger vertrauenswürdig sind. Ein SSL/TLS-Zertifikat dient der Browser-Verifikation der Serveridentität – doch schon innerhalb eines Jahres können sich viele Dinge ändern: Unternehmen können ihre Geschäftstätigkeit einstellen oder fusionieren, Domains verkauft werden, Kontaktdaten sich ändern. Wie Apple in seiner Begründung darlegte, „werden Zertifikatsdaten mit der Zeit zunehmend unzuverlässig“, und dieses Problem lässt sich nur durch häufigere Revalidierung beheben. Kürzere Laufzeiten erzwingen häufigere Erneuerungen und damit regelmäßige Bestätigung, dass die Domain noch demselben Besitzer gehört und Organisationsdaten (bei OV/EV) aktuell sind.
Ein weiterer zentraler Aspekt ist die Begrenzung der Auswirkungen von Schlüsselkompromittierungen oder fehlerhaften Zertifikatausstellungen. Wird ein privater Zertifikatsschlüssel gestohlen oder ein Zertifikat versehentlich an einen unberechtigten Empfänger ausgegeben, beschränkt die kurze Laufzeit das Missbrauchsfenster erheblich – ein kompromittiertes Zertifikat läuft innerhalb von 47 Tagen automatisch ab. Das ist besonders wichtig, da das aktuelle Widerrufssystem (CRL/OCSP) oft fehleranfällig ist und Browser Widerrufsstatus wegen Verzögerungen oder Ausfällen häufig ignorieren. Praktisch kann ein widerrufenes Zertifikat von Browsern akzeptiert werden, solange es nicht formal abgelaufen ist. Kürzere Laufzeiten mildern dieses Problem: Ein potenziell kompromittiertes oder fehlerhaft ausgestelltes Zertifikat wird schnell ungültig, selbst wenn CRL/OCSP es nicht erfasst. Bereits 2023 genehmigte das CA/B Forum sogenannte kurzfristige Zertifikate mit ≤ 7 Tagen Gültigkeit, die gänzlich ohne CRL/OCSP-Handling auskommen – ihre kurze Lebensdauer ist selbst Schutz genug. Zusammengefasst erhöht die kürzere Gültigkeit die Sicherheit, indem sie das Risiko von Angriffen im Fall einer Kompromittierung minimiert.
Der zweite fundamentale Grund ist die Notwendigkeit der Automatisierung bei Ausstellung und Erneuerung von Zertifikaten. Manuelles Management war bei Jahres- oder Zweijahreszyklen noch machbar, wird aber bei Erneuerungen im Abstand von wenigen Wochen praktisch unmöglich. Das CA/Browser Forum hat durch sukzessive Verkürzung der maximalen Laufzeiten immer wieder signalisiert, dass die Branche *auf automatisches Lifecycle-Management umsteigen muss. Apple stellte in seinem Antrag klar, dass Organisationen ohne Automatisierung bei so kurzen Zyklen nicht bestehen können. Bereits bei 100-Tage-Zertifikaten (ab 2027) werden manuelle Prozesse unhaltbar und das Risiko von massenhaften Zertifikatsabläufen steigt. Kurz gesagt, Automatisierung wird von einer „nützlichen Option“ zur absoluten Notwendigkeit für die Betriebsstabilität.
Der Druck seitens der Branchenführer hat diese Entwicklung beschleunigt. Apple und Google befürworteten die Verkürzung öffentlich, betonten Vorteile für Sicherheit und Zuverlässigkeit. Google kündigte 2023 einen 90-Tage-Grenzwert an, Apple legte einen noch kürzeren Vorschlag vor – und gewann damit Unterstützung von Browser-Anbietern (Google, Mozilla) und großen CAs (z. B. Sectigo). Am Ende einigte sich die Branche auf den Weg: vollständige Automatisierung kombiniert mit kurzen Zertifikaten, was die Entscheidung besiegelte. Zudem begünstigt der kürzere Zyklus schnelle Reaktionen auf neue Bedrohungen – etwa den Umstieg auf post-quantensichere Kryptografie, wenn aktuelle Algorithmen Schwächen zeigen.
Die drastische Verkürzung der Zertifikatslaufzeiten wird den Alltag in der IT-Infrastruktur stark beeinflussen. Administratoren müssen deutlich häufiger neue Zertifikate installieren und ausrollen. Anstelle der bisherigen jährlichen Erneuerung erfordert ein 47-Tage-Zyklus etwa 7–8 Erneuerungen pro Jahr (Üblicherweise einige Tage vor Ablauf). Das entspricht einem über achtfachen Aufwand im Vergleich zu heute. Schon die Umstellung auf 90-Tage-Zertifikate wurde auf etwa 4–6 Erneuerungen pro Jahr geschätzt; bei 47 Tagen spricht man von Zyklen im Abstand von ca. 40–45 Tagen. Infrastruktur-Teams müssen sich auf permanentes Zertifikatsmanagement einstellen, was ihre operative Belastung deutlich erhöht. Ohne durchgängige Automatisierung steigt das Risiko von Fehlern und Ausfällen – etwa wenn eine Erneuerung verpasst wird und ein Zertifikat abläuft, was zu Dienstunterbrechungen führt.
Um diese Herausforderungen zu bewältigen, muss die Infrastruktur von entsprechenden Tools und Prozessen unterstützt werden. Notwendig sind Systeme für automatische Erneuerung und Verteilung von Zertifikaten. Webserver und Netzwerkgeräte sollten Mechanismen nutzen, die neue Zertifikate und private Schlüssel automatisch importieren und aktivieren ohne Downtime. Viele moderne Server (z. B. Nginx, Apache, Application Server) unterstützen Live-Reload von Zertifikaten – entscheidend ist jedoch eine Orchestrierung, die in regelmäßigen Abständen neue Zertifikate von der CA abruft und überall aktualisiert. In containerisierten Umgebungen und Orchestratoren (Kubernetes) kommen vermehrt Operatoren oder Controller (z. B. cert-manager) zum Einsatz, die ACME integrieren und Zertifikate automatisch von vertrauenswürdigen CAs beziehen sowie deployen. Organisationen, die bisher manuell in Wartungsfenstern Zertifikate hochgeladen haben, müssen diese Praxis überdenken. Die hohe Taktung (alle paar Wochen) erfordert einen „Zero-Downtime“-Ansatz – Zertifikatswechsel erfolgt im Hintergrund, bevor das alte abläuft, und bleibt für Nutzer unsichtbar.
Auch DevOps– und CI/CD-Prozesse (Continuous Integration/Continuous Delivery) müssen sich an den schnelleren Zertifikatslebenszyklus anpassen. Viele Organisationen werden Zertifikatsmanagement als integralen Bestandteil ihrer Deployment-Pipelines betrachten. So kann ein Pipeline-Job bei jeder Bereitstellung automatisch die API einer Zertifizierungsstelle aufrufen (z. B. per ACME), um Zertifikate für neue oder aktualisierte Services zu erzeugen bzw. zu erneuern. Infrastructure as Code muss Zertifikat-Definitionen enthalten, und Configuration Management Tools müssen sicherstellen, dass Zertifikate vor Ablauf automatisch erneuert und verteilt werden. DevOps-Teams sind daher angehalten, Zertifikatstools eng in bestehende Automatisierungsplattformen zu integrieren (Orchestrierungs-Tools, CI-Server, Cloud-Lösungen).
Ein weiterer Aspekt ist Monitoring und Testing in Pipelines. Bei so häufigen Erneuerungen sollte Monitoring automatisch alle Zertifikatsablaufdaten überwachen und bei Problemen Alarm schlagen. Best Practices umfassen regelmäßige Tests der Renewal-Mechanismen (z. B. in Staging-Umgebungen) sowie den Einsatz von Canary Deployments für neue Zertifikate – so kann vor dem produktiven Rollout sichergestellt werden, dass alle Systemkomponenten das neue Zertifikat korrekt akzeptieren. CI/CD-Pipelines können zudem Security-Tests integrieren, um sicherzustellen, dass keine veralteten Zertifikate im Einsatz sind.
Insgesamt lässt sich diese Veränderung als Teil des Trends „Everything as Code“ verstehen – Zertifikate werden zu dynamischen, automatisiert erneuerten Ressourcen, die wie Code oder Konfiguration gemanagt werden müssen. Organisationen, die früh auf automatische Erneuerung gesetzt haben, profitieren; andere sehen darin einen Impuls zur Modernisierung ihrer Pipelines. Der ACME-Standard gewinnt weiter an Bedeutung als universelle Schnittstelle für automatisches Zertifikatsmanagement – viele DevOps-Tools unterstützen ihn bereits oder planen entsprechende Integrationen, um Zertifikaterneuerung nahtlos in den Delivery-Cycle einzubinden.
In Enterprise-Umgebungen mit Hunderten oder Tausenden von Zertifikaten wird der 47-Tage-Zyklus besonders spürbar. Das traditionelle Modell, bei dem jede Business Unit manuell ein Zertifikat bestellt und das IT-Team es einmal jährlich installiert, skaliert in einem monatlichen Erneuerungsrhythmus nicht mehr. Große Unternehmen müssen in zentralisierte Certificate Lifecycle Management (CLM)-Systeme investieren, die ermöglichen, alle unternehmensweiten Zertifikate zu inventarisieren, automatisch vor Ablauf zu erneuern und in die entsprechenden Systeme zu verteilen. Viele Organisationen werden Lösungen wie Venafi, DigiCert CertCentral, DigiCert One, Sectigo CLM, GlobalSign Atlas oder Open-Source-Tools mit ACME und internen Skripten einführen. Entscheidend ist ein vollständiges Zertifikatsinventar und automatisierte Alarmmechanismen, damit kein Zertifikat (etwa in selten genutzten Systemen) unbemerkt verfällt.
Die Rolle der Prozessstandardisierung für Zertifikate wird deutlich zunehmen. Viele Konzerne haben bereits eine „keine dezentral verwalteten Zertifikate“-Politik – die neue Regel zwingt zur Ausweitung solcher Vorgaben. Die Automatisierung muss sowohl öffentliche Domains als auch interne Zertifikate in Firmennetzwerken umfassen (obwohl interne Zertifikate nicht dem CA/B Forum unterliegen, gilt der Automatisierungstrend dennoch). Große Unternehmen können auch den Einsatz von Wildcard- oder Multi-Domain-Zertifikaten verstärken, um die Gesamtzahl der zu erneuernden Einheiten zu reduzieren – obwohl die Erneuerungsfrequenz unverändert bleibt, vereinfacht es das Management, wenn ein Zertifikat mehrere Dienste abdeckt.
Finanzielle Mehrkosten für Unternehmen dürften nicht signifikant steigen. Die meisten CAs arbeiten längst mit Abonnementmodellen (z. B. Jahres- oder Mehrjahresabos), bei denen unbegrenzt Zertifikate innerhalb der Laufzeit ausgestellt oder erneuert werden können. Statt für jede Ausstellung extra zu zahlen (was bei achtmal mehr Erneuerungen sehr teuer wäre), erwirbt man ein Jahresabo und erneuert darin beliebig oft. CAs betonen, dass der Umstieg auf 100-Tage- und kürzere Zertifikate keine höheren Gebühren nach sich zieht – die Jahresgebühr bleibt gleich, und Zertifikate lassen sich mehrfach erneuern. Selbstverständlich müssen Unternehmen in Automatisierungs- und Integrationssysteme investieren (Software, Rollout, Schulungen), aber langfristig senkt diese Automatisierung Ausfallkosten und reduziert versteckte Kosten durch Zertifikatsvorfällen.
Für den durchschnittlichen Internetnutzer wird diese Änderung kaum wahrnehmbar sein, sofern Service-Provider die neuen Vorgaben korrekt umsetzen. Die kürzere Zertifikatsgültigkeit beeinflusst nicht den Ablauf verschlüsselter Verbindungen – der Browser zeigt weiterhin das TLS-Schlosssymbol an, und die Verschlüsselung bleibt identisch. Nutzer bemerken allenfalls, dass die Ablaufdaten der Zertifikate (einsehbar über das Schlosssymbol) näher am aktuellen Datum liegen, was rein informativen Charakter hat.
Erfolgt die Umstellung planmäßig, profitieren Endnutzer indirekt von höherer Sicherheit – die Wahrscheinlichkeit sinkt, auf ein zwar formal gültiges, aber kompromittiertes oder veraltetes Zertifikat zu stoßen. Kürzere Zertifikatszyklen zwingen Administratoren, Nachlässigkeiten zu beseitigen, was zu weniger Service-Ausfällen aufgrund abgelaufener Zertifikate führt. Prominente Vorfälle, bei denen große Websites plötzlich wegen abgelaufener Zertifikate unerreichbar waren, sollten mit flächendeckender Automatisierung der Vergangenheit angehören. Für Nutzer bedeutet dies letztlich stabilere und zuverlässigere Online-Dienste.
Übergangsrisiken bestehen jedoch – bleiben einige Anbieter bei der Automatisierung hinterher oder erwischt sie die Verkürzung unvorbereitet, kann es vorübergehend zu mehr Warnungen über ungültige oder abgelaufene Zertifikate kommen. Doch der Druck durch Browser (die nicht konforme Zertifikate blockieren können) und die Angst vor Kundenverlusten wird ernsthafte Anbieter rechtzeitig mobilisieren. Langfristig erfolgt der Wandel im Hintergrund – Nutzer werden vor allem die positiven Effekte in Form sichererer und stabilerer Verbindungen wahrnehmen.
Ein solcher Einschnitt im TLS-Ökosystem bringt operative Herausforderungen und messbare Effekte mit sich. Zunächst wird die Anzahl der Ausstellung-/Erneuerungsanfragen an Zertifizierungsstellen drastisch steigen. Anstelle einer jährlichen Erneuerung muss ein Webseitenbetreiber rund 8 Prozesse pro Jahr durchführen. Global gerechnet bedeutet das eine bis zu achtfache Zunahme der Transaktionen zwischen Kunden und CA-Infrastruktur. Schon heute haben 60–70 % aller Zertifikate eine Gültigkeit von ≤ 90 Tagen – ein Ergebnis der enormen Verbreitung automatischer Dienste wie Let’s Encrypt. Mit dem Limit von 47 Tagen wird jedoch jeder Zertifikatstyp zur Kurzlebigkeit, sodass die jährliche Gesamtzahl ausgestellter öffentlicher TLS-Zertifikate in die Hunderte Millionen bis Milliarden steigen dürfte. Let’s Encrypt etwa hat bereits vor einigen Jahren Hunderte Millionen 90-Tage-Zertifikate jährlich ausgestellt – ein Indikator dafür, dass die Infrastruktur skaliert. Kommerzielle CAs müssen dennoch ihre Systeme optimieren, um das stark gestiegene Anfragevolumen per API/ACME ohne manuelle Eingriffe zu bewältigen.
Das erhöhte Erneuerungsaufkommen wirkt sich auch auf Netz- und Service-Last der CAs aus. ACME ist relativ leichtgewichtig (Anfrage, Domain-Validation, Zertifikatsabruf), doch global multipliziert stellen selbst einige Dutzend KB multipliziert mit Hunderten Millionen Vorgängen eine Herausforderung dar. CA-Provider investieren daher in Redundanz und Skalierbarkeit, um nahezu 100 % Verfügbarkeit zu garantieren – kurze Laufzeiten lassen keinen Ausfallspielraum: Selbst vorübergehende Störungen könnten ansonsten zum Ablauf zahlreicher Zertifikate führen, bevor eine Erneuerung gelingt. Möglicherweise entstehen Failover-ACME-Konzepte, bei denen bei Ausfall des Haupt-CA automatisch auf alternative Anbieter ausgewichen wird – allerdings wirft das Fragen zu Vertrauen und Compliance auf.
Ein weiterer Punkt ist die steigende Anzahl von Einträgen in öffentlichen Certificate Transparency (CT)-Logs – jedes neue Zertifikat muss registriert werden, weshalb die Logs schneller wachsen. Zum Glück ist das CT-System für hohe Skalierung ausgelegt, und die Verkürzung wurde bereits lange debattiert, sodass Log-Betreiber vorbereitet sein sollten.
Zusammengefasst sind die operativen Herausforderungen beträchtlich: Lawinenartige Zunahme des Transaktionsvolumens, Verlässliche Automatisierung und der Betrieb einer leistungsfähigen CA-Infrastruktur. Die meisten großen Zertifizierungsstellen haben jedoch bereits automatische Protokolle und APIs implementiert, und viele Unternehmen haben Anpassungen vorgenommen, noch bevor die Änderung verpflichtend wurde. Wer jetzt nicht nachzieht, läuft Gefahr, im Zeitalter manueller Zertifikatsverwaltung endgültig abgehängt zu werden.
Trotz anfänglicher Hürden bringt die Verkürzung der maximalen Zertifikatsgültigkeit auf 47 Tage zahlreiche Vorteile für Branche und Nutzer. Die wichtigsten sind:
Die Verkürzung der maximalen Gültigkeit von SSL/TLS-Zertifikaten auf 47 Tage ist ein beispielloser Wandel, der eine neue Ära im Public-Key-Infrastructure-Management einläutet. Die zugrunde liegenden Motive – Erhöhung der Sicherheit, Eliminierung fehleranfälliger manueller Prozesse und Beschleunigung von Innovation – sind klar und spiegeln sich in der einhelligen Unterstützung durch Browserhersteller und Zertifikataussteller wider. Für Administratoren und IT-Teams beginnen intensive Vorbereitungen: Automatisierung der Abläufe, Aktualisierung von Tools und Schulung des Personals werden Priorität haben. Wer bereits ACME oder andere automatische Erneuerungssysteme implementiert hat, wird den Übergang reibungslos meistern; alle anderen sollten schnell nachziehen, um Unterbrechungsrisiken zu vermeiden. Letztendlich profitieren jedoch alle – von großen Konzernen bis zu Betreibern kleiner Websites – von den langfristigen Vorteilen. Das Internet wird durch häufiger verifizierte, frische Zertifikate sicherer, und Vorfälle ausgelaufener oder veralteter Zertifikate werden zur Seltenheit. Kurzlebige Zertifikate sind zugleich Katalysator für Automatisierung und Innovation im Bereich Identitäts- und Sicherheitsmanagement. Man kann sagen, dass die Entscheidung für 47-Tage-Zertifikate, so anspruchsvoll sie auch ist, Teil des allgemeinen Trends hin zu Vereinfachung, Automatisierung und gestärktem Vertrauen in digitale Infrastrukturen ist. Sie markiert einen bedeutenden Schritt, der das Internet für uns alle zuverlässiger macht.
Haben Sie Fragen zur Einführung einer automatisierten SSL-Lifecycle-Management-Lösung? Kontaktieren Sie unser Vertriebsteam.