SC-081v3: TLS-Zertifikate mit 47 Tagen Laufzeit, warum und wie du dich vorbereitest
Von CaptainDNS
Veröffentlicht am 19. März 2026
- SC-081v3 verabschiedet: Die maximale Laufzeit von TLS-Zertifikaten sinkt von 398 Tagen auf 47 Tage bis März 2029, in 3 Phasen (200 T. in 2026, 100 T. in 2027, 47 T. in 2029)
- Die DCV-Wiederverwendung sinkt ebenfalls: von 398 Tagen auf 10 Tage, was bei jeder Verlängerung eine nahezu kontinuierliche Domain-Revalidierung erfordert
- Automatisierung ist keine Option mehr: Ohne ACME oder Äquivalent ist die manuelle Verlängerung alle 47 Tage nicht haltbar
- Erfahre auch, wie SC-085v2 die DNSSEC-Validierung durch CAs vorschreibt, eine ergänzende Maßnahme, die am selben Tag in Kraft getreten ist
Der 15. März 2026 markiert einen Wendepunkt für das TLS-Ökosystem. Zwei Ballots des CA/Browser Forums treten gleichzeitig in Kraft: SC-085v2, das Zertifizierungsstellen zur DNSSEC-Validierung bei der Zertifikatsausstellung verpflichtet, und die erste Phase von SC-081v3, die die maximale Laufzeit von TLS-Zertifikaten von 398 auf 200 Tage reduziert. Das Zusammentreffen ist kein Zufall: Beide Texte sind Teil derselben Neugestaltung des Vertrauens im Web.
SC-081v3 wurde im April 2025 vom CA/Browser Forum mit überwältigender Mehrheit verabschiedet: 25 Stimmen dafür, 0 dagegen, 5 Enthaltungen. Apple, Initiator des Vorschlags, wurde von Google, Mozilla und Microsoft unterstützt. Die Botschaft ist klar: Die Ära der Einjahres-Zertifikate ist vorbei. Bis März 2029 wird die maximale Laufzeit eines TLS-Zertifikats 47 Tage betragen, und die Wiederverwendung von Domain-Validierungsnachweisen (DCV) wird auf 10 Tage begrenzt sein.
Dieser Artikel behandelt die vollständige Geschichte der Laufzeitreduzierungen, die Details des Ballots SC-081v3, die technischen Gründe für diese Änderung, die Ausfälle, die die Entscheidung beschleunigt haben, die ACME-Automatisierung, die Rolle von Let's Encrypt, die Auswirkungen auf kostenpflichtige Zertifikate, die Wechselwirkung mit SC-085v2 und DNSSEC sowie einen Praxisleitfaden zur Vorbereitung deiner Infrastruktur.
Sind deine Zertifikatsverlängerungen automatisiert?
Von 10 Jahren auf 47 Tage: die Geschichte der Reduzierung
Die Laufzeit von TLS-Zertifikaten ist seit der Einführung des Systems kontinuierlich gesunken. Jede Reduzierung hat Widerstände hervorgerufen, gefolgt von einer schnellen Anpassung der Branche. Das Schema ist konstant: Ein Akteur erzwingt eine Änderung, das Ökosystem passt sich an, und niemand kehrt zurück.
Vor 2012: bis zu 10 Jahre. Die ersten Versionen der SSL-Zertifikate sahen keine strikte Laufzeitbegrenzung vor. Zertifikate mit 8 bis 10 Jahren Gültigkeit waren im Umlauf. Die Sperrung beruhte auf CRL-Listen, die selten abgefragt wurden. Das Kompromittierungsrisiko über einen solchen Zeitraum war erheblich, aber die Kosten der Zertifikate (mehrere hundert Dollar) motivierten dazu, ihre Laufzeit zu maximieren.
2012: 5 Jahre (Baseline Requirements v1). Das CA/Browser Forum veröffentlicht die erste Version der Baseline Requirements. Die maximale Laufzeit wird auf 60 Monate festgelegt. Dies ist die erste globale Normierung der Ausstellungspraktiken für TLS-Zertifikate.
2015: 39 Monate. Ballot 193 reduziert die Laufzeit auf 39 Monate. Die Branche passt sich ohne größere Zwischenfälle an. Dreijahres-Zertifikate werden zur Norm für Unternehmenskunden.
2018: 825 Tage. Erneute Reduzierung auf 825 Tage (etwa 27 Monate) durch das überarbeitete Ballot 193. Zweijahres-Zertifikate setzen sich durch. Let's Encrypt, 2015 gestartet, hat bereits 90-Tage-Zertifikate populär gemacht und bewiesen, dass Automatisierung im großen Maßstab funktioniert.
2020: 398 Tage (Apples Alleingang). Apple kündigt im Februar 2020 einseitig an, dass Safari keine Zertifikate mit mehr als 398 Tagen akzeptiert, die nach dem 1. September 2020 ausgestellt werden. Google und Mozilla folgen innerhalb weniger Wochen. Das CA/Browser Forum musste nicht abstimmen: Die Browser-Hersteller haben die Änderung über ihre Root Programs durchgesetzt. Die Branche murrt, passt sich aber innerhalb weniger Monate an.
2023: Google schlägt 90 Tage vor. In seiner Roadmap "Moving Forward, Together" schlägt Google vor, die maximale Laufzeit auf 90 Tage zu reduzieren. Der Vorschlag wird nicht sofort abgestimmt, eröffnet aber die Debatte.
2024: SC-081v1 zurückgezogen, v2 scheitert. Die erste Version des Ballots wird vor der Abstimmung zurückgezogen. SC-081v2 wird zur Abstimmung gestellt, verfehlt aber die erforderliche Supermajorität. Mehrere CAs lehnen den als zu aggressiv bewerteten Zeitplan ab. Die Ballots SC-22 und 185, die ähnliche Reduzierungen anstrebten, waren bereits in den Vorjahren gescheitert.
April 2025: SC-081v3 verabschiedet. Die dritte Version findet den Konsens. Der Zeitplan erstreckt sich über 4 Phasen zwischen 2026 und 2029, wodurch die Branche genügend Zeit zur Anpassung erhält. Abstimmungsergebnis: 25 dafür, 0 dagegen, 5 Enthaltungen.
Das Schema ist eindeutig: Jede Reduzierung wurde bekämpft, dann übernommen und einige Jahre später als unzureichend betrachtet. Die Richtung ist unumkehrbar.
Ballot SC-081v3: was sich konkret ändert
SC-081v3 verkürzt nicht nur die Laufzeit der Zertifikate. Es reduziert auch die Wiederverwendungsdauer der Domain-Validierungsnachweise (DCV Reuse), was eine nahezu kontinuierliche Revalidierung erzwingt.
Die 4 Phasen der Reduzierung
| Phase | Inkrafttreten | Max. Zertifikatslaufzeit | Max. DCV-Wiederverwendung |
|---|---|---|---|
| Phase 0 (aktuell) | Vor dem 15. März 2026 | 398 Tage | 398 Tage |
| 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 |
Die DCV-Wiederverwendung verstehen
Die Domain Control Validation (DCV) ist der Prozess, mit dem eine CA überprüft, ob der Antragsteller die Domain kontrolliert. Aktuell kann ein DCV-Nachweis 398 Tage lang wiederverwendet werden: Wenn du deine Domain heute validierst, kann die CA innerhalb der nächsten 398 Tage ein neues Zertifikat ausstellen, ohne erneut einen Nachweis zu verlangen.
SC-081v3 reduziert dieses Wiederverwendungsfenster parallel zur Zertifikatslaufzeit. In Phase 3 sinkt die DCV-Wiederverwendung auf 10 Tage. Konkret bedeutet das: Jede Zertifikatsverlängerung erfordert eine neue Domain-Validierung, da ein 47-Tage-Zertifikat vor Ablauf verlängert werden muss und der DCV-Nachweis nur 10 Tage gültig ist.
Warum 47 Tage und keine runde Zahl?
Die Zahl 47 ist nicht willkürlich. Sie entspricht einem Verlängerungszyklus von 30 Tagen plus einem Puffer von 17 Tagen. Die Idee: Wenn der ACME-Client das Zertifikat 30 Tage vor Ablauf verlängert (wie es die meisten Clients empfehlen), bleiben 17 Tage Spielraum bei einem Fehlschlag. Eine Verlängerung pro Monat, mit einem Sicherheitsnetz von mehr als zwei Wochen.
Was sich nicht ändert
SC-081v3 gilt für alle Typen öffentlicher TLS-Zertifikate: DV (Domain Validation), OV (Organization Validation) und EV (Extended Validation). Es gibt keine Ausnahme für OV- oder EV-Zertifikate, wie manche Kommentatoren gehofft hatten. Die Unterscheidung DV/OV/EV betrifft den Umfang der Identitätsprüfung der Organisation, nicht die Laufzeit des Zertifikats.
Die gescheiterten Versuche
SC-081v3 ist nicht der erste Versuch einer Reduzierung. Mehrere Ballots waren im Laufe der Jahre gescheitert. Ballot 185 (2017) schlug eine Reduzierung auf 13 Monate vor und wurde abgelehnt. Ballot SC-22 versuchte eine Reduzierung auf 397 Tage und scheiterte. SC-081v1 wurde vor der Abstimmung zurückgezogen. SC-081v2 erreichte die erforderliche Supermajorität auf CA-Seite nicht. Die v3 war erfolgreich, indem sie den Zeitplan streckte und in jeder Phase einen ausreichenden Puffer einbaute.
Warum kürzere Zertifikate?
Die Reduzierung der Zertifikatslaufzeit adressiert mehrere strukturelle Probleme des TLS-Ökosystems. Keines davon lässt sich mit den aktuellen Mechanismen lösen.
Die Sperrung ist kaputt
Der Mechanismus zur Ungültigkeitserklärung eines kompromittierten Zertifikats funktioniert in der Praxis nicht. Certificate Revocation Lists (CRL) erreichen Hunderte von Megabyte: Die CRL von Let's Encrypt überschritt 300 MB, bevor OCSP aufgegeben wurde. OCSP (Online Certificate Status Protocol) leidet unter dem Soft-Fail-Problem: Wenn der OCSP-Server nicht antwortet, akzeptiert der Browser das Zertifikat standardmäßig, was die Prüfung nutzlos macht. Chrome hat OCSP durch CRLSets ersetzt, eine kompakte Liste, die nur etwa 2 % der widerrufenen Zertifikate abdeckt. Let's Encrypt hat OCSP Ende 2024 offiziell aufgegeben und damit das Scheitern des Mechanismus anerkannt.
Mit 47-Tage-Zertifikaten wird die Sperrung weniger kritisch. Ein kompromittiertes Zertifikat läuft natürlich innerhalb weniger Wochen ab, was das Ausnutzungsfenster begrenzt, ohne auf einen fehlerhaften Sperrmechanismus angewiesen zu sein.
Krypto-Agilität und Post-Quanten-Migration
Kurze Zertifikate erleichtern die Migration zu neuen kryptografischen Algorithmen. Das NIST hat im August 2024 die finalen Standards für Post-Quanten-Kryptografie veröffentlicht: ML-KEM (Key Encapsulation) und ML-DSA (Digital Signatures). Die Umstellung auf diese Algorithmen erfordert den Austausch bestehender Zertifikate. Mit 47-Tage-Zertifikaten migriert das gesamte Ökosystem in maximal 47 Tagen, verglichen mit über einem Jahr bei 398-Tage-Zertifikaten.
Reduziertes Kompromittierungsfenster
Ein kompromittiertes 398-Tage-Zertifikat kann über ein Jahr lang ausgenutzt werden. Mit 47 Tagen sinkt das maximale Ausnutzungsfenster auf weniger als 7 Wochen. Das ist eine Reduzierung von 88 %. Wird ein privater Schlüssel gestohlen, hat der Angreifer nur wenige Wochen statt über einem Jahr Zeit, ihn auszunutzen.
Erzwungene Automatisierung reduziert Ausfälle
Paradoxerweise reduzieren kürzere Zertifikate die Ausfälle durch Ablauf. Der Grund: Sie erzwingen Automatisierung. Ein 398-Tage-Zertifikat kann manuell verwaltet (schlecht), vergessen und dann abrupt ablaufen. Ein 47-Tage-Zertifikat lässt keine Wahl: Ohne Automatisierung ist die Verlängerung nicht zu bewältigen. Organisationen, die automatisieren, erleiden keine Ablauf-Ausfälle mehr.
Ausrichtung am Zero-Trust-Modell
Das Zero-Trust-Modell basiert auf kontinuierlicher Überprüfung. Ein 398-Tage-Zertifikat gewährt implizites Vertrauen für über ein Jahr, was dem Prinzip widerspricht. Kurze Zertifikate erzwingen eine häufige Neuüberprüfung der Server-Identität und bringen die Web-PKI mit den Zero-Trust-Prinzipien in Einklang.
Die Ausfälle, die alles verändert haben
Mehrere schwerwiegende Vorfälle haben die Konsequenzen einer manuellen Zertifikatsverwaltung demonstriert. Jeder Ausfall hat das Argument für Automatisierung und Laufzeitreduzierung verstärkt.
Equifax (2017): 147,9 Millionen Personen betroffen
Im März 2015 lässt Equifax ein SSL-Zertifikat auf einem Netzwerk-Traffic-Inspektionsgerät ablaufen. Dieses seit 19 Monaten abgelaufene Zertifikat verhindert die Erkennung eines aktiven Eindringens. Die Angreifer nutzen eine ungepatchte Apache-Struts-Schwachstelle 76 Tage lang aus und exfiltrieren die persönlichen Daten von 147,9 Millionen Personen. Die Gesamtkosten übersteigen 1,38 Milliarden Dollar. Die Untersuchung zeigt, dass das Unternehmen über 300 Zertifikate manuell verwaltete, ohne zentrales Inventar.
Ericsson/O2 UK (2018): 32 Millionen Nutzer ohne Netz
Am 6. Dezember 2018 läuft ein Ericsson-Zwischenzertifikat auf der Netzwerkinfrastruktur von O2 UK ab. Der Ablauf verursacht einen Totalausfall des Mobilfunknetzes für 32 Millionen Abonnenten über mehr als 12 Stunden. SoftBank in Japan erleidet am selben Tag einen identischen Ausfall. Die geschätzten Kosten übersteigen 133 Millionen Dollar. Das Zertifikat mit einer Laufzeit von 15 Jahren war installiert und vergessen worden.
Microsoft Teams (2020): 3 Stunden weltweiter Ausfall
Am 3. Februar 2020 erleidet Microsoft Teams einen 3-stündigen Ausfall mitten im COVID-19-bedingten Nutzungsanstieg. Die Ursache: ein abgelaufenes Authentifizierungszertifikat. Der Vorfall betrifft Millionen von Nutzern im Homeoffice zu einem Zeitpunkt, als Teams für Tausende von Unternehmen zu einem kritischen Tool geworden ist.
Let's Encrypt (2021): der Ablauf eines historischen Root-Zertifikats
Am 30. September 2021 läuft das Root-Zertifikat DST Root CA X3 ab, das Let's Encrypt für die Kompatibilität mit älteren Geräten nutzte. Millionen von Geräten mit Android 7.1 und älter verlieren den Zugang zu Websites, die Let's Encrypt verwenden. Der Vorfall verdeutlicht die Komplexität der Verwaltung von Root-Zertifikaten und die Notwendigkeit agiler Vertrauensketten.
Der gemeinsame Nenner dieser Vorfälle: Jeder Ausfall involvierte ein manuell verwaltetes, vergessenes Zertifikat oder eines, dessen Laufzeit die betrieblichen Anforderungen weit überschritt.
ACME und die obligatorische Automatisierung
Mit 47-Tage-Zertifikaten und einer DCV-Wiederverwendung von 10 Tagen wird die manuelle Verlängerung für jede Infrastruktur mit mehr als einer Handvoll Zertifikaten physisch unmöglich. ACME (Automatic Certificate Management Environment) ist das Protokoll, das die Automatisierung ermöglicht.
Das ACME-Protokoll (RFC 8555)
ACME standardisiert den Dialog zwischen einem Client (deinem Server) und einer CA. Der Prozess folgt drei Schritten: Der Client beweist, dass er die Domain kontrolliert (Challenge), die CA überprüft den Beweis und stellt dann das Zertifikat aus. Es gibt drei Typen von Challenges:
- HTTP-01: Der Client platziert eine Datei unter einer bestimmten URL. Die CA prüft, ob die Datei erreichbar ist. Einfach, aber nicht kompatibel mit Wildcard-Zertifikaten.
- DNS-01: Der Client veröffentlicht einen TXT-Record unter
_acme-challenge.captaindns.com. Die CA fragt das DNS ab. Wildcard-kompatibel, ideal für automatisierte Umgebungen. - TLS-ALPN-01: Der Client konfiguriert ein temporäres Zertifikat mit einer spezifischen ALPN-Erweiterung. Nützlich, wenn man weder DNS noch Webserver kontrolliert.
ACME-Clients
Das Ökosystem der ACME-Clients ist ausgereift und deckt alle Umgebungen ab:
- Certbot: Der Referenz-Client, gepflegt von der EFF. Kompatibel mit Linux, macOS, Windows. Plugins für Apache und NGINX.
- acme.sh: Reines Shell-Skript, ohne Abhängigkeiten. Über 150 DNS-APIs werden für den dns-01-Challenge unterstützt.
- Lego: Go-Client, beliebt in containerisierten Umgebungen und CI/CD-Pipelines.
- Caddy: Webserver mit integriertem ACME. Bezieht und verlängert Zertifikate automatisch, ohne Konfiguration.
- Traefik: Cloud-nativer Reverse Proxy mit integriertem ACME. Verwaltet Zertifikate für alle Backends.
ACME in der Cloud
Die großen Cloud-Anbieter integrieren die Zertifikatsautomatisierung:
- AWS Certificate Manager (ACM): Kostenlose Zertifikate mit automatischer Verlängerung für AWS-Dienste (ALB, CloudFront, API Gateway).
- Google Cloud Managed Certificates: Automatische Verlängerung für GCP-Load-Balancer.
- Azure App Service Managed Certificates: Kostenlose Zertifikate mit automatischer Verlängerung.
- Cloudflare: Edge- und Origin-Zertifikate automatisch verwaltet, mit Unterstützung für 15-Tage-Zertifikate.
ACME Renewal Information (ARI, RFC 9773)
ARI ist eine ACME-Erweiterung, die es der CA ermöglicht, dem Client das optimale Verlängerungsfenster mitzuteilen. Statt systematisch bei einem festen Prozentsatz der Restlaufzeit zu verlängern, fragt der Client die CA nach dem idealen Zeitpunkt. Das erlaubt der CA, die Last zu glätten und eine vorzeitige Verlängerung bei Schlüsselkompromittierung zu signalisieren. Let's Encrypt unterstützt ARI seit 2024.
NGINX und das native ACME-Modul
Im August 2025 hat NGINX ein natives ACME-Modul veröffentlicht, das dem Webserver ermöglicht, seine Zertifikate direkt zu beziehen und zu verlängern, ohne externen Client. Diese Integration vereinfacht die Bereitstellung erheblich für Umgebungen, die NGINX als Frontend einsetzen.
Enterprise-Lösungen
Für große Organisationen, die Tausende von Zertifikaten verwalten, orchestrieren CLM-Lösungen (Certificate Lifecycle Management) die Verlängerung im großen Maßstab:
- HashiCorp Vault PKI: In Vault integrierte PKI-Engine mit automatisierter Ausstellung und Rotation.
- Venafi / CyberArk: Enterprise-CLM-Plattform (CyberArk hat Venafi 2024 für 1,54 Milliarden Dollar übernommen).
- Keyfactor: Plattform zur Verwaltung des Lebenszyklus von Zertifikaten und Maschinenidentitäten.
- Sectigo Certificate Manager: CLM mit integriertem ACME, deckt öffentliche und private Zertifikate ab.
Let's Encrypt als Wegbereiter
Let's Encrypt hat nicht auf SC-081v3 gewartet, um die Branche in Richtung kurzer Zertifikate zu drängen. Die kostenlose und automatisierte Zertifizierungsstelle hält einen Marktanteil von etwa 63,9 % bei Web-TLS-Zertifikaten und stellt mehr als 10 Millionen Zertifikate pro Tag aus. Ihr Einfluss auf das Ökosystem ist beträchtlich.
6-Tage-Zertifikate in Produktion
Seit Januar 2026 bietet Let's Encrypt 6-Tage-Zertifikate in allgemeiner Verfügbarkeit an. Diese ultra-kurzen Zertifikate richten sich an hochautomatisierte Umgebungen (CDN, Cloud-Plattformen, CI/CD), in denen die Verlängerung vollständig von ACME gesteuert wird. Das Ziel: beweisen, dass sehr kurze Laufzeiten im industriellen Maßstab funktionieren.
Auf dem Weg zu 45-Tage-Zertifikaten als Standard
Let's Encrypt hat einen Übergangsplan zu 45-Tage-Zertifikaten als Standard angekündigt. Der Zeitplan sieht eine Opt-in-Phase ab Mai 2026 vor, gefolgt von der Umstellung auf den Standard von 45 Tagen im Februar 2028. Diese Vorwegnahme des SC-081v3-Zeitplans (der 47 Tage ab März 2029 vorschreibt) gibt dem Ökosystem ein Jahr Vorsprung, um die Automatisierungs-Pipelines zu validieren.
Die Abschaffung von OCSP
Ende 2024 hat Let's Encrypt die schrittweise Abschaffung von OCSP angekündigt, die 2025 abgeschlossen wurde. Der Grund: OCSP funktioniert nicht (Soft-Fail in Browsern, Datenschutzprobleme, Serverlast). Diese Entscheidung hat die Diskussion der Branche über die Sperrung beschleunigt und das Argument für kurze Zertifikate verstärkt. Wenn die Sperrung nicht funktioniert, ist die einzige Alternative, die Laufzeit der Zertifikate zu begrenzen.
Let's Encrypt beweist jeden Tag, dass Automatisierung im großen Maßstab funktioniert. Über 400 Millionen Websites nutzen seine Zertifikate. Der Übergang zu 47 Tagen wird für bereits automatisierte Umgebungen kein Problem sein: Es wird ein Nicht-Ereignis.
Auswirkungen auf kostenpflichtige Zertifikate und das CA-Ökosystem
SC-081v3 transformiert das Geschäftsmodell der Zertifizierungsstellen und stellt den Mehrwert kostenpflichtiger Zertifikate infrage.
OV und EV: weiterhin gültig, aber kürzer
OV-Zertifikate (Organization Validation) und EV-Zertifikate (Extended Validation) bleiben verfügbar. Die Organisationsvalidierung (Überprüfung der Unternehmensidentität, Adresse, Registrierungsnummer) bietet weiterhin einen eigenständigen Wert gegenüber der einfachen Domain-Validierung. Aber die Zertifikatslaufzeit wird gleichermaßen reduziert: 200 Tage in 2026, 100 Tage in 2027, 47 Tage in 2029. Ein 47-Tage-EV-Zertifikat erfordert den gleichen Verlängerungsrhythmus wie ein DV-Zertifikat.
Der Schwenk zu Abonnements und CLM
Die kostenpflichtigen CAs stellen ihr Geschäftsmodell um. Statt einzelne Zertifikate mit fester Laufzeit zu verkaufen, bieten sie Jahresabonnements mit unbegrenzten Verlängerungen und integriertem ACME-Client an. DigiCert, Sectigo und GlobalSign bieten alle CLM-Plattformen (Certificate Lifecycle Management), die die ACME-Verlängerung für OV- und EV-Zertifikate automatisieren.
Die Konsolidierung des CA-Marktes
Die Übernahme von Venafi durch CyberArk für 1,54 Milliarden Dollar im Jahr 2024 veranschaulicht die Marktkonsolidierung. Der Wert verschiebt sich von der Zertifikatsausstellung hin zur Lebenszyklusverwaltung. CAs, die keine integrierte Automatisierung anbieten, verlieren Marktanteile an Let's Encrypt und CLM-Lösungen.
Wildcards und Multi-SAN
Wildcard-Zertifikate (*.captaindns.com) und Multi-SAN-Zertifikate (mehrere Domains auf einem Zertifikat) erfordern den DNS-01-Challenge zur Validierung. Bei Verlängerungen alle 47 Tage wird die Automatisierung des DNS-01-Challenge über die API des DNS-Anbieters unverzichtbar. Die großen DNS-Anbieter (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) bieten alle APIs, die mit ACME-Clients kompatibel sind.
Automatisierung stellt das kostenpflichtige Zertifikat infrage
Die ACME-Automatisierung schafft gleiche Bedingungen. Ein kostenloses Let's-Encrypt-DV-Zertifikat, das alle 47 Tage automatisch verlängert wird, bietet das gleiche Verschlüsselungsniveau wie ein kostenpflichtiges EV-Zertifikat. Der Unterschied beschränkt sich auf die Browser-Adressleiste (die seit 2019 den Organisationsnamen nicht mehr anzeigt) und die mit dem Zertifikat verbundene finanzielle Garantie. Für die Mehrheit der Websites rechtfertigt dieser Unterschied die Mehrkosten nicht mehr.
Wechselwirkung mit SC-085v2: DNSSEC und häufige Verlängerungen
SC-081v3 und SC-085v2 treten im selben Monat in Kraft und erzeugen einen Multiplikatoreffekt auf die DNS-Vertrauenskette. Um SC-085v2 im Detail zu verstehen, lies unseren dedizierten Artikel.
Der Multiplikatoreffekt
Mit SC-085v2 umfasst jede Domain-Validierung (DCV) nun eine DNSSEC-Überprüfung. Mit SC-081v3 Phase 3 bedeutet ein 47-Tage-Zertifikat etwa 8 Verlängerungen pro Jahr statt 1. Jede Verlängerung löst eine DCV aus, und jede DCV überprüft DNSSEC. Die Anzahl der DNSSEC-Überprüfungen im Zusammenhang mit Zertifikaten wird also mit 8 multipliziert.
Ausfallszenario: defektes DNSSEC + kurze Zertifikate
Betrachten wir ein konkretes Szenario. Dein TLS-Zertifikat läuft in 15 Tagen ab. Dein ACME-Client startet die Verlängerung. Die CA führt die DNS-01-Validierung durch und überprüft DNSSEC gemäß SC-085v2. Aber eine DNSSEC-Schlüsselrotation ist fehlgeschlagen: Der DS-Record beim TLD stimmt nicht mehr mit dem KSK deiner Zone überein. Der Resolver der CA gibt BOGUS zurück, die DCV schlägt fehl, das Zertifikat wird nicht verlängert.
Mit einem 398-Tage-Zertifikat hast du Monate, um das Problem zu erkennen und zu beheben. Mit einem 47-Tage-Zertifikat hast du bestenfalls 17 Tage (der im Verlängerungszyklus eingebaute Puffer). Wenn das DNSSEC-Problem bestehen bleibt, läuft dein Zertifikat ab und deine Website wird unerreichbar.
DANE/TLSA-Rotation und kurze Zertifikate
Wenn du DANE verwendest, um deine TLS-Zertifikate über DNSSEC-signierte TLSA-Records zu authentifizieren, muss die Rotation der TLSA-Records mit dem Rhythmus der Zertifikatsverlängerungen Schritt halten. Bei einem 47-Tage-Zertifikat muss der TLSA-Record bei jeder Verlängerung aktualisiert werden (außer im DANE-EE-Modus 3 1 1 mit SPKI, der die Verlängerung überlebt, solange sich der öffentliche Schlüssel nicht ändert). Lies unseren DANE/TLSA-Leitfaden für Rotationsstrategien.
Einheitliche Pipeline: die Empfehlung
Die Kombination SC-081v3 + SC-085v2 erfordert einen einheitlichen Ansatz. Die Pipeline zur Zertifikatsverlängerung muss integrieren:
- Die ACME-Verlängerung des TLS-Zertifikats
- Die vorherige Überprüfung der DNSSEC-Kette
- Die Aktualisierung der DANE/TLSA-Records bei Bedarf
- Die kontinuierliche Überwachung aller drei Komponenten
Diese Elemente separat zu behandeln, vervielfacht die Fehlerstellen. Eine einheitliche Pipeline, die DNSSEC vor dem Start der ACME-Verlängerung überprüft und anschließend TLSA nach der Ausstellung aktualisiert, reduziert das Ausfallrisiko erheblich.
Praxisleitfaden: deine Infrastruktur vorbereiten
Der Übergang zu 47-Tage-Zertifikaten erfolgt in 4 Phasen über 3 Jahre. Jede Phase bringt strengere Anforderungen. Hier sind die 6 Schritte zur Vorbereitung deiner Infrastruktur.
Schritt 1: Alle Zertifikate inventarisieren
Bevor du automatisierst, musst du wissen, was du verwaltest. Nutze mehrere Quellen für ein vollständiges Inventar:
- Certificate Transparency Logs: Frage die CT-Logs (crt.sh) ab, um alle für deine Domains ausgestellten Zertifikate aufzulisten.
- Netzwerk-Scan: Verwende Tools wie
sslyzeodernmap, um aktive Zertifikate in deiner Infrastruktur zu entdecken. - CLM-Tools: Plattformen wie Keyfactor oder Venafi Discovery scannen dein Netzwerk und deine Clouds, um nicht erfasste Zertifikate zu identifizieren.
- Unser DNSSEC Checker: Überprüfe die DNSSEC-Vertrauenskette, unverzichtbar für die Zertifikatsverlängerung seit SC-085v2.
Dokumentiere für jedes Zertifikat: die Domain, die ausstellende CA, das Ablaufdatum, den Typ (DV/OV/EV), den Verlängerungsmodus (manuell oder automatisiert) und den Verantwortlichen.
Schritt 2: Einen geeigneten ACME-Client einsetzen
Wähle einen ACME-Client, der zu deiner Umgebung passt:
- Standalone-Webserver: Certbot mit dem passenden Plugin (Apache, NGINX) oder Caddy mit integriertem ACME.
- Containerisierte Umgebung: cert-manager für Kubernetes, Lego für CI/CD-Pipelines.
- Cloud-Infrastruktur: AWS ACM, Google Cloud Managed Certificates oder Azure App Service Managed Certificates.
- Gemischte Umgebung: acme.sh für seine Flexibilität und Kompatibilität mit über 150 DNS-APIs.
Teste die Verlängerung mit einem Dry-Run, bevor du in Produktion gehst. Validiere, dass der Client ohne menschliches Eingreifen verlängern kann.
Schritt 3: DNS-Validierung automatisieren
Für den DNS-01-Challenge (erforderlich für Wildcard-Zertifikate) muss dein ACME-Client TXT-Records über die API deines DNS-Anbieters erstellen und löschen können. Konfiguriere die API-Zugänge mit minimalen Berechtigungen: Erstellen und Löschen von TXT-Records ausschließlich unter _acme-challenge.
Wenn dein DNS-Anbieter keine API anbietet, wechsle zu einem Anbieter, der eine hat. Im Jahr 2026 ist das Fehlen einer DNS-API ein Blocker.
Schritt 4: Deine DNSSEC-Kette überprüfen
Mit SC-085v2 blockiert eine fehlerhafte DNSSEC-Kette die Zertifikatsverlängerung. Überprüfe:
- Das Vorhandensein und die Gültigkeit des DS-Records beim TLD
- Die Übereinstimmung zwischen DS und dem in deiner Zone veröffentlichten KSK
- Die Gültigkeit der RRSIG-Signaturen (Ablaufdaten)
- Die Automatisierung der ZSK- und KSK-Schlüsselrotation
Lies unseren Leitfaden zur DNSSEC-Vertrauenskette für technische Details. Verwende den DNSSEC Checker für eine vollständige Diagnose.
Schritt 5: Überwachung einrichten
Setze Alerts auf drei Achsen ein:
- Ablauf der TLS-Zertifikate: Alarm bei 30 Tagen, 14 Tagen und 7 Tagen vor Ablauf.
- DNSSEC-Signaturen (RRSIG): Alarm, wenn die Signaturen sich ihrem Ablaufdatum nähern.
- DANE/TLSA-Records: Überprüfung, dass die TLSA-Records mit dem aktiven Zertifikat übereinstimmen.
Die Überwachung ist das Sicherheitsnetz, das Automatisierungsfehler erkennt, bevor sie zu Ausfällen werden.
Schritt 6: Schrittweise Migration planen
Warte nicht bis März 2029, um auf 47 Tage umzusteigen. Verfolge einen schrittweisen Plan:
- Ab sofort: Automatisiere alle Zertifikate mit 90-Tage-Laufzeiten (Let's Encrypt Standard).
- 2026: Teste die 6-Tage-Zertifikate von Let's Encrypt in einer Staging-Umgebung.
- 2027: Gehe in Produktion mit Zertifikaten von 100 Tagen oder weniger.
- 2028: Aktiviere die 45-Tage-Zertifikate von Let's Encrypt (Opt-in), um deine Pipeline vor der Frist zu validieren.
- 2029: Der Übergang zu 47 Tagen ist ein Nicht-Ereignis, deine Infrastruktur ist bereit.
Aktionsplan: deine Infrastruktur vorbereiten
- Alle Zertifikate inventarisieren: Discovery über CT-Logs, Netzwerk-Scan, CLM-Tools
- Einen ACME-Client einsetzen: Certbot, acme.sh oder Lego je nach Umgebung
- DNS-Validierung automatisieren: DNS-Anbieter-API für den DNS-01-Challenge
- DNSSEC überprüfen: Gültige Vertrauenskette, automatisierte Schlüsselrotationen
- Überwachung einrichten: Alerts für Zertifikatsablauf + RRSIG + TLSA
- Mit kurzen Zertifikaten testen: Let's Encrypt 90 T. dann 6 T. zur Pipeline-Validierung
FAQ
Was ist das Ballot SC-081v3 des CA/Browser Forums?
SC-081v3 ist ein im April 2025 vom CA/Browser Forum verabschiedetes Ballot, das die maximale Laufzeit öffentlicher TLS-Zertifikate schrittweise reduziert. Die Laufzeit sinkt von 398 Tagen auf 200 Tage (März 2026), dann 100 Tage (März 2027), dann 47 Tage (März 2029). Es reduziert auch die Wiederverwendungsdauer der Domain-Validierungsnachweise (DCV) auf 10 Tage in der letzten Phase.
Wann werden 47-Tage-Zertifikate verpflichtend?
Zertifikate mit maximal 47 Tagen werden am 15. März 2029 verpflichtend (Phase 3 des Ballots). Vor diesem Datum gelten zwei Übergangsphasen: maximal 200 Tage ab dem 15. März 2026 und maximal 100 Tage ab dem 15. März 2027. Vor dem jeweiligen Stichtag ausgestellte Zertifikate bleiben bis zu ihrem natürlichen Ablauf gültig.
Werden meine aktuellen Zertifikate widerrufen?
Nein. Bereits ausgestellte Zertifikate bleiben bis zu ihrem Ablaufdatum gültig, unabhängig von der aktuellen Phase. SC-081v3 gilt nur für neue Zertifikate, die nach dem jeweiligen Inkrafttreten ausgestellt werden. Ein 398-Tage-Zertifikat, das am 14. März 2026 ausgestellt wird, bleibt für seine gesamte Laufzeit gültig.
Warum 47 Tage und keine runde Zahl?
Die Zahl 47 entspricht einem Verlängerungszyklus von 30 Tagen plus einem Puffer von 17 Tagen. Wenn der ACME-Client 30 Tage vor Ablauf verlängert (die empfohlene Praxis), bleiben 17 Tage Spielraum bei einem Fehlschlag der Verlängerung. Dieser Puffer ermöglicht es, Probleme zu erkennen und zu beheben, bevor das Zertifikat tatsächlich abläuft.
Sind EV- und OV-Zertifikate betroffen?
Ja. SC-081v3 gilt für alle Typen öffentlicher TLS-Zertifikate, einschließlich DV, OV und EV. Es gibt keine Ausnahme. Die Unterscheidung zwischen diesen Typen betrifft den Umfang der Identitätsprüfung der Organisation, nicht die Laufzeit des Zertifikats. Ein EV-Zertifikat wird ab März 2029 ebenso auf 47 Tage begrenzt wie ein DV-Zertifikat.
Was ist die Reduzierung der DCV-Wiederverwendung?
Die DCV-Wiederverwendung (Domain Control Validation) erlaubt es einer CA, einen Domain-Kontrollnachweis wiederzuverwenden, um mehrere Zertifikate auszustellen, ohne erneut eine Validierung anzufordern. SC-081v3 reduziert dieses Fenster von 398 Tagen auf 10 Tage in der letzten Phase. Konkret erfordert jede Zertifikatsverlängerung in Phase 3 einen neuen Domain-Kontrollnachweis.
Muss ich zu Let's Encrypt wechseln?
Nicht unbedingt. Let's Encrypt ist eine solide Option für automatisierte DV-Zertifikate, aber auch andere CAs unterstützen ACME: DigiCert, Sectigo, GlobalSign und ZeroSSL bieten alle ACME-Endpoints an. Wenn du OV- oder EV-Zertifikate benötigst, musst du bei einer kostenpflichtigen CA bleiben, aber mit einem ACME-Client für die automatisierte Verlängerung.
Wie funktioniert ACME für die automatische Verlängerung?
ACME (RFC 8555) automatisiert den Dialog zwischen deinem Server und der CA. Der ACME-Client beweist, dass du die Domain kontrollierst (über einen HTTP-01-, DNS-01- oder TLS-ALPN-01-Challenge), die CA überprüft den Beweis und stellt dann das Zertifikat aus. Der Client plant anschließend die automatische Verlängerung vor Ablauf. Der gesamte Prozess läuft ohne menschliches Eingreifen ab.
Was ist der Zusammenhang zwischen SC-081v3 und SC-085v2 (DNSSEC)?
SC-085v2 verpflichtet CAs, DNSSEC bei der DCV zu validieren. SC-081v3 vervielfacht die DCVs durch die Verkürzung der Zertifikatslaufzeit. Kombiniert erzeugen diese beiden Ballots einen Multiplikatoreffekt: 8 Verlängerungen pro Jahr (47 Tage) bedeuten 8 DNSSEC-Überprüfungen statt 1. Ein defektes DNSSEC blockiert daher schneller und häufiger die Verlängerung deiner Zertifikate.
Sind interne Zertifikate (private PKI) betroffen?
Nein. SC-081v3 gilt nur für Zertifikate, die von öffentlich anerkannten CAs ausgestellt werden (deren Root-Zertifikat in den Vertrauensspeichern der Browser enthalten ist). Zertifikate, die von einer internen privaten PKI deiner Organisation ausgestellt werden, unterliegen nicht den Baseline Requirements des CA/Browser Forums und sind von dieser Reduzierung nicht betroffen.
Glossar
- CA/Browser Forum: Konsortium aus Zertifizierungsstellen und Browser-Herstellern. Es veröffentlicht die Baseline Requirements, den normativen Rahmen, den alle öffentlichen CAs einhalten müssen, damit ihre Zertifikate von Browsern akzeptiert werden.
- Ballot: Änderungsvorschlag zu den Baseline Requirements, der den Mitgliedern des CA/Browser Forums zur Abstimmung vorgelegt wird. Ein Ballot muss eine Supermajorität auf CA-Seite und Einstimmigkeit auf Browser-Seite erhalten, um angenommen zu werden.
- DCV (Domain Control Validation): Prozess, bei dem eine CA überprüft, ob der Antragsteller eines Zertifikats tatsächlich die Domain kontrolliert. Gängige Methoden sind DNS-01, HTTP-01 und E-Mail. Die DCV-Wiederverwendung ermöglicht es, einen bestehenden Nachweis für spätere Ausstellungen wiederzuverwenden.
- ACME (Automatic Certificate Management Environment): Standardisiertes Protokoll (RFC 8555) zur Automatisierung der Ausstellung und Verlängerung von TLS-Zertifikaten. Verwendet von Let's Encrypt, Certbot, acme.sh, Lego und cert-manager.
- CRL (Certificate Revocation List): Liste der von einer CA widerrufenen Zertifikate. CRLs sind umfangreich (mehrere hundert MB) und werden von Browsern selten abgefragt, was ihre Wirksamkeit einschränkt.
- OCSP (Online Certificate Status Protocol): Protokoll zur Echtzeit-Überprüfung des Sperrstatus eines Zertifikats. In der Praxis ignorieren Browser OCSP-Fehler (Soft-Fail), was den Mechanismus unwirksam macht. Let's Encrypt hat OCSP 2025 eingestellt.
- Krypto-Agilität: Fähigkeit eines Systems, schnell auf neue kryptografische Algorithmen zu migrieren. Kurze Zertifikate erleichtern diese Migration, indem sie den Zeitraum begrenzen, in dem ein veralteter Algorithmus im Einsatz bleibt.
- DANE/TLSA: Protokoll, das es ermöglicht, im DNS (über DNSSEC-signierte TLSA-Records) das erwartete Zertifikat eines Servers zu veröffentlichen. Eliminiert die Abhängigkeit von CAs für die Zertifikatsauthentifizierung.
