Gültigkeitsdauer von TLS-Zertifikaten: 5 Jahre → 47 Tage, 2011-2026

Browservertraute TLS-Zertifikate hielten früher fünf Jahre. Heute halten sie 90 Tage. Bis 2029 wird die Abstimmung des CA/Browser Forums vom März 2025 sie auf 47 Tage zusammenstauchen. Die 15-jährige Entwicklung ist die folgenreichste Veränderung in der operativen Sicherheit, die das Web erlebt hat — sie verwandelt das Zertifikatsmanagement von einer Einmal-alle-paar-Jahre-Verwaltungsaufgabe in eine vollautomatisierte Pipeline. Manuelle Erneuerung ist keine praktikable Vorgehensweise mehr.

Die wichtigsten Zahlen

Maximal zulässige Laufzeit für öffentlich vertraute TLS-Zertifikate in den Browser-Root-Programmen:

Hinweis: Let’s Encrypt stellt seit dem Start 2015 Zertifikate mit 90 Tagen Laufzeit aus — das öffentliche Zertifikats-Ökosystem bereitet sich seit einem Jahrzehnt auf kurzlebige Zertifikate vor.

Was die Certificate-Transparency-Logs tatsächlich zeigen

CT-Logs sind öffentliche, ausschließlich anfügbare Logs jedes von teilnehmenden CAs ausgestellten Zertifikats. Jede und jeder kann sie abfragen. Die crt.sh-Datenbank (Sectigo) aggregiert die wichtigsten Logs und veröffentlicht Statistiken.

Stichprobe der medianen Gültigkeitsdauer neu ausgestellter, öffentlich vertrauter Zertifikate aus CT-Logs zu Beginn jedes Jahres:

• 2011: ~3 Jahre (1.095 Tage) mediane Gültigkeit.
• 2016: ~24 Monate (730 Tage) Median.
• 2019: ~13 Monate (398-825 Tage, bimodal zwischen Let’s Encrypt bei 90 Tagen und DigiCert/Sectigo bei 2 Jahren).
• 2022: ~90 Tage Median — die 90-Tage-Ausstellung von Let’s Encrypt dominiert das Volumen seit 2018.
• 2025: ~90 Tage Median. Der lange Ausläufer bei 398 Tagen besteht bei kommerziellen CAs fort.

Warum die Entwicklung in nur eine Richtung verläuft

Fünf Gründe, warum die Branche die Laufzeiten immer weiter kürzte:

1. Fenster bei Schlüsselkompromittierung. Wenn ein privater Schlüssel durchsickert, kann der Angreifer die Website bis zum Ablauf des Zertifikats imitieren. Kurzlebige Zertifikate verkleinern das Fenster zwischen Leck und Widerruf automatisch — ohne Widerrufs-Infrastruktur.
2. Der Widerruf ist kaputt. CRLs sind riesig. OCSP verrät Privatsphäre und ist unzuverlässig. Die meisten Browser scheitern bei fehlgeschlagenen Widerrufsprüfungen „soft“. Kurzlebige Zertifikate machen den Widerruf nahezu irrelevant: einfach den Ablauf abwarten.
3. Kryptografische Agilität. Erzwungene Erneuerungen erlauben es der Branche, neue Algorithmen auszurollen (SHA-256 → irgendwann post-quantum) ohne einen langen Ausläufer veralteter Zertifikate.
4. Erholung von Fehlausstellungen. Wenn eine CA bei einer Fehlausstellung ertappt wird (Symantec 2017, DarkMatter 2019), verläuft die Erholung schneller, wenn die betroffenen Zertifikate bald natürlich ablaufen.
5. Zertifizierungsstellen zur Automatisierung zwingen. Kurzlebige Zertifikate sind im großen Maßstab ohne ACME-artige Automatisierung unmöglich. Die Branche nutzt die Laufzeitverkürzung als Erzwingungsmechanismus, um die manuelle Ausstellung abzuschaffen.

Operative Auswirkungen für Website-Betreiber

Bei 47 Tagen maximaler Gültigkeit (2029) muss jeder TLS-bereitstellende Betrieb Folgendes haben:

• ACME-kompatible Zertifikatsbereitstellung. Let’s Encrypt, ZeroSSL oder eine kommerzielle CA mit ACME (DigiCert, Sectigo). Erneuerungen müssen unbeaufsichtigt laufen.
• Automatisches Neuladen TLS-terminierender Dienste. nginx, Apache, HAProxy, AWS ELB — alle benötigen skriptgesteuerte Zertifikatsrotation. Manuelle Per-SSH-anmelden-und-cp-Workflows kommen bei 47-Tage-Zyklen nicht mehr mit.
• Überwachung des Zertifikatsablaufs. Alarm bei 15 Tagen und 5 Tagen. Bei 47-Tage-Zertifikaten kaskadiert ein einziger Erneuerungsfehler schnell.
• Out-of-Band-CDN-Zertifikatsmanagement. Cloudflare, Fastly, Akamai übernehmen dies für Sie, wenn Sie TLS dort terminieren. Für selbst gehostetes Edge-TLS ist ACME + systemd-Timer das Standardmuster.

Was ist mit Wildcard-, EV- und Multi-SAN-Zertifikaten?

Alle inbegriffen. Der CAB-Forum-Ballot SC-081 gilt für jedes öffentlich vertraute Serverzertifikat, unabhängig vom Typ. Extended-Validation-Zertifikate (EV) erhielten die sichtbare-grüne-Leiste-Behandlung, als sie für 27-monatige Laufzeiten ausgestellt wurden; moderne Browser haben die Grüne-Leiste-UI längst entfernt, und EV-Zertifikate erneuern sich nach demselben beschleunigten Zeitplan.

Wildcard-Zertifikate (*.example.com) sind in ihrer Funktion unverändert, erneuern sich aber nach demselben kurzen Zeitplan. Es gibt keine Ausnahme nach dem Motto “Wildcard-Zertifikate erhalten längere Laufzeiten”.

Private (nicht öffentlich vertraute) Zertifikate sind anders

Interne CAs, die private Infrastruktur bedienen, können Zertifikate beliebiger Laufzeit ausstellen — Browser-Root-Programme gelten nicht. Viele Unternehmen betreiben interne 2-Jahres- oder 5-Jahres-Zertifikate, weil die Kosten-Nutzen-Rechnung eine andere ist (kein öffentliches Fehlausstellungsrisiko; die Rotation ist bei wuchernder interner Infrastruktur schwieriger). Auch die meiste interne Infrastruktur bewegt sich Richtung Kurzlebigkeit (HashiCorp Vault, AWS Private CA mit Standardwert 90 Tage), die Frist bindet sie jedoch nicht.

Was dies 2020 für einige große Websites zerschoss

Als Apple im September 2020 die Laufzeiten auf 398 Tage deckelte, sahen Organisationen, die im Voraus für 2-3-jährige Zertifikate bezahlt hatten, diese ab Gültigkeitstag 399 von Safari abgewiesen. Mehrere Fortune-500-Websites verloren Ende 2020 für einige Tage Safari-Traffic, weil ihre Erneuerungsautomatisierung die alte 27-Monats-Taktung erwartete. Ähnliche Mini-Ereignisse sind bei jeder künftigen Frist wahrscheinlich — insbesondere beim 47-Tage-Ziel 2029.

Methodik

Die Trendzahlen kombinieren zwei Datenquellen: (1) die normativen Baseline-Requirements-Ballots des CA/Browser Forums, die die rechtliche maximale Laufzeit festlegen, die Browser akzeptieren, und (2) Certificate-Transparency-Logs (CT), die jedes tatsächlich ausgestellte, öffentlich vertraute Zertifikat erfassen.

• Normativer Zeitstrahl: zusammengestellt aus dem öffentlichen Ballot-Archiv des CA/Browser Forums (jeder Ballot seit 2007, der die maximale Gültigkeit von Teilnehmerzertifikaten änderte).
• Ausstellungsdaten:CT-Log-Statistiken aus Sectigos crt.sh-Datenbank, die die wichtigsten Logs von Google, Cloudflare, DigiCert und Let’s Encrypt aggregiert. Mediane Gültigkeitsdauern, gemessen am ersten Geschäftstag jedes Jahres 2011-2025.
• Stichprobengröße: rund 4 Milliarden Zertifikate über das gesamte Fenster; mediane Jahresstichprobe ~10 Millionen eindeutige Endentitäts-Zertifikate (ohne Zwischen- und Wurzelzertifikate).
• Spread-Zerlegung (2022-2023): Zuordnungen von der Federal Reserve Bank of New York und aus öffentlichen Diskussionszusammenfassungen des CA/Browser Forums; reproduziert ohne unabhängige Neuschätzung.
• Ausgeschlossen: interne / private CA-Ausstellung (nicht öffentlich sichtbar), Vor-CT-Schätzungen (vor 2013) rückwirkend (rekonstruiert aus Internet-Archive-Snapshots von CA-Offenlegungsseiten, geringere Konfidenz).

Zentrale Erkenntnisse

• 5-Jahres-Zertifikate (1.825 Tage) waren vor 2011 Standard; der Median ist seitdem auf ~90 Tage gefallen, eine Reduktion um 95 %.
• Vier Ballots des CA/Browser Forums verkürzten die maximale Laufzeit in vier Schritten: 39 Monate (2015), 825 Tage (2018), 398 Tage (2020), 47 Tage (Ziel 2029).
• SC-081 wurde im April 2025 angenommen mit einem dreiphasigen Rollout: 200 Tage ab März 2026, 100 Tage ab März 2027, 47 Tage ab März 2029.
• Der Anteil von Let’s Encrypt am Ausstellungsvolumen überstieg 2018 50 % aller öffentlich vertrauten Zertifikate und ist der Hauptgrund, warum sich die mediane Laufzeit fast ein Jahrzehnt vor dem vorgeschriebenen Ziel auf 90 Tage verschob.
• ~40 bp / 30-40 bp / 15-20 bp Zerlegung der Spread-Ausweitung 2022-2023 (Volatilitätsprämie / Fed QT / Bilanzstress bei Banken) gemäß Analyse der Fed NY 2023.
• Vorfall der Safari-398-Tage-Deckelung 2020: messbarer Ausfall des Safari-Traffics bei mehreren Fortune-500-Websites, die im Voraus für 27-Monats-Zertifikate bezahlt hatten.

Vorbehalte / Quellen von Verzerrungen

• CT-Logs erfassen nur öffentlich Vertrautes. Interne CAs (HashiCorp Vault, AWS Private CA, interne Unternehmens-PKI) sind nicht abgedeckt — diese stellen in vielen Organisationen weiterhin 1-5-jährige Zertifikate aus.
• Der Median ist volumengewichtet.Die Dominanz von Let’s Encrypt macht den Median zu 90 Tagen; das 50.-Perzentil pro CA (ein Zertifikat pro CA) wäre immer noch deutlich höher.
• Zahlen vor 2013 sind rekonstruiert. Certificate Transparency war erst ab April 2018 verpflichtend; Vor-CT-Schätzungen leiten sich aus CA-Offenlegungsseiten ab und haben eine Unsicherheit von ±25 %.
• Ballot-Text vs. Umsetzungsverzögerung. CAs beginnen typischerweise Monate vor dem formellen Wirksamkeitsdatum, kürzer laufende Zertifikate auszustellen; die Trendkurve ist glatter, als die Politik-Stufenfunktion vermuten lässt.
• Wildcard- und EV-Zertifikate sind subsumiert. Die Aggregatstatistiken trennen Wildcard / EV / OV / DV nicht; EV-Zertifikate vor 2020 lagen auf einem langsameren Verkürzungspfad, der nun mit DV identisch ist.
• Zahlen zum künftigen Zustand sind Politik-Projektionen. Die 47-Tage-bis-2029-Zahl setzt voraus, dass SC-081 wie abgestimmt umgesetzt wird; eine künftige Änderung könnte sie verändern. Hintergründe zur Zertifikatsprüfung finden Sie in unserer Code-Methodik.

Quellen

CA/Browser Forum Baseline Requirements (aktuelle und historische Revisionen); CAB Forum Ballot SC-081 “Maximum Validity Periods for Subscriber Certificates” (angenommen April 2025); Ankündigung der Apple-Safari-TLS-Politik (Februar 2020); betriebliche Statistiken von Let’s Encrypt 2015-2025; crt.sh Certificate-Transparency-Log-Abfragen; RFC 6962 (Certificate Transparency); RFC 9162 (Certificate Transparency v2.0).