SaaSFort Ballot SC-081v3 wurde im April 2025 im CA/Browser Forum mit neunundzwanzig Ja-Stimmen und keiner Gegenstimme angenommen. Apple hat ihn eingebracht. Google, Mozilla und Microsoft stimmten zu.
Er senkt die maximale Laufzeit eines öffentlich vertrauenswürdigen TLS-Zertifikats von 398 Tagen auf 47, in drei Stufen.
| Ab | Maximale Laufzeit | Erneuerungen pro Jahr |
|---|---|---|
| 15.03.2026 | 200 Tage | ~2 |
| 15.03.2027 | 100 Tage | ~4 |
| 15.03.2029 | 47 Tage | ~8 |
Die erste Stufe gilt bereits. Jedes heute ausgestellte Zertifikat ist auf 200 Tage begrenzt.
Die Stufe, die wirklich etwas zerbricht, ist 2027
Die meisten Teams überstehen 200 Tage ohne Änderung, weil eine halbjährliche Erneuerung noch etwas ist, das ein Mensch im Kalender halten kann.
Bei 100 Tagen hört das auf. Vier Erneuerungen pro Jahr, über jede Domain und jede Subdomain, mit einem harten Fehlerfall, der das Produkt offline nimmt und jedem Besucher eine Browser-Warnseite zeigt. Teams, die manuell erneuern, werden das Problem so entdecken, wie man solche Dinge immer entdeckt: an einem Wochenende.
Parallel läuft eine zweite, weniger beachtete Änderung. Die Wiederverwendung der Domain-Control-Validierung sinkt bis 2029 auf 10 Tage. Heute validieren Sie eine Domain einmal und nutzen diese Validierung über ein Jahr. Künftig weisen Sie die Kontrolle über jede Domain etwa dreimal im Monat neu nach. Kein manueller Prozess übersteht das.
Warum es die Obergrenze gibt
Zwei Argumente, beide stichhaltig.
Das erste ist die Eindämmung von Kompromittierungen. Ein abgeflossener privater Schlüssel bleibt ausnutzbar, solange das Zertifikat gültig ist. Der Widerruf soll das auffangen und tut es weitgehend nicht, weil die Prüfung von Widerrufen in der Praxis unzuverlässig ist. Ein Zertifikat mit 398 Tagen gibt einem Angreifer bis zu dreizehn Monate. Eines mit 47 Tagen höchstens sieben Wochen.
Das zweite ist Krypto-Agilität. Kurze Laufzeiten bedeuten, dass sich der gesamte Zertifikatsbestand des Webs schnell erneuert, sodass eine künftige Algorithmenmigration, etwa hin zu Post-Quantum-Signaturen, Wochen statt Jahre dauert. Die Zahl 47 wurde bewusst gewählt: kurz genug, um manuelle Erneuerung im Maßstab unmöglich zu machen, lang genug, damit Automatisierung einen Fehlversuch abfängt und erneut zustellt.
Was zu tun ist
Ausstellung mit ACME automatisieren. Das Werkzeug ist ausgereift und kostenlos.
- certbot, der Referenzclient, geeignet für eine Handvoll Hosts.
- lego, eine einzelne Go-Binärdatei, gut für CI und ungewöhnliche DNS-Anbieter.
- cert-manager, die richtige Antwort auf Kubernetes, wo er ohne menschliches Zutun erneuert und neu lädt.
Wichtiger als das Werkzeug ist das Prinzip: Die Erneuerungsfrequenz muss von der Zertifikatslaufzeit entkoppelt sein. Konfigurieren Sie die Erneuerung bei einem festen Bruchteil der Restlaufzeit, typischerweise einem Drittel, damit eine erneute Absenkung der Obergrenze keine Anpassung erfordert. Teams, die “30 Tage vor Ablauf erneuern” fest verdrahten, müssen das noch zweimal überarbeiten.
Dann extern überwachen. Automatisierung, die still stehen bleibt, ist schlimmer als keine, denn sie entfernt den Menschen, dem es früher auffiel.
Die Prüfung, die die meisten Scanner falsch machen
Es gibt zwei verschiedene Fragen zu einem Zertifikat, und sie werden regelmäßig vermengt.
Wann läuft es ab? Die operative Frage. Sie sagt Ihnen, ob die Seite nächsten Dienstag ausfällt.
Für wie lange wurde es ausgestellt? Die Prozessfrage. Ein Zertifikat mit 300 Tagen Laufzeit sagt Ihnen, dass der Ausstellungsprozess älter ist als die geltenden Regeln, oder dass das Team das längstmögliche Zertifikat kauft und von Hand erneuert.
Nur die zweite sagt den Ausfall voraus, den Sie 2027 haben werden. Sie ist auch diejenige, die gegen die zum Ausstellungszeitpunkt geltende Obergrenze zu bewerten ist und nicht gegen das heutige Datum, denn ein Zertifikat mit 398 Tagen aus dem Jahr 2025 war bei seiner Ausstellung vollständig konform und ist weiterhin gültig.
Wer das falsch macht, baut einen Scanner, der jedes rechtmäßig ausgestellte Altzertifikat durchfallen lässt. Genau so bringt ein Werkzeug Teams dazu, es zu ignorieren.
Zuordnung zu Rahmenwerken
- NIS2 Artikel 21(2)(h), Kryptografie und Verschlüsselung.
- ISO/IEC 27001:2022 A.8.24, Einsatz von Kryptografie.
- DORA Artikel 9, für Finanzunternehmen.
Prüfer fragen zunehmend nicht nur, ob Zertifikate gültig sind, sondern wie die Erneuerung erfolgt. “Manuell, durch das Plattformteam” ist eine Antwort, die inzwischen die Rückfrage provoziert, was geschieht, wenn diese Person im Urlaub ist.
Selbst prüfen
echo | openssl s_client -connect ihredomain.de:443 2>/dev/null \
| openssl x509 -noout -dates
Ziehen Sie notBefore von notAfter ab. Liegt das Ergebnis über 100 Tagen, muss sich Ihre Erneuerungskadenz vor März 2027 ändern. Liegt es über 200 Tagen bei einem nach dem 15.03.2026 ausgestellten Zertifikat, stimmt etwas mit Ihrem Ausstellungsweg nicht.
Kurzfassung
Die Frist ist nicht 2029. Die Frist ist der 15.03.2027, denn das ist die Stufe, die einen heute noch menschlich leistbaren Prozess zerbricht.
Automatisieren Sie jetzt, solange es ein geplantes Vorhaben ist und kein Zwischenfall.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.