Ein TLS-Zertifikat war lange ein Wartungsobjekt, an das man einmal im Jahr dachte: ausstellen, einbinden, ein Jahr Ruhe. Das ist vorbei. Das CA/Browser-Forum, das gemeinsame Gremium von Zertifizierungsstellen und Browserherstellern, hat 2025 mit dem Ballot SC-081v3 beschlossen, die maximale Laufzeit von TLS-Zertifikaten stufenweise von heute 398 Tagen (CA/Browser-Forum) auf 47 Tage (CA/Browser-Forum) im Jahr 2029 zu senken. Die erste Kürzung auf 200 Tage (CA/Browser-Forum) greift bereits ab dem 15. März 2026. Für Shop-Betreiber verschiebt das eine scheinbar triviale Aufgabe an eine kritische Stelle: Wer die Erneuerung weiter von Hand über Kalendererinnerungen steuert, erhöht die Zahl der Erneuerungen bis 2029 auf rund das Achtfache – und jedes vergessene Zertifikat nimmt den Shop mit einer formatfüllenden Sicherheitswarnung sofort offline. Dieser Leitfaden zeigt, warum die Laufzeiten sinken, was der Zeitplan konkret bedeutet und wie ACME-basierte Automatisierung die Erneuerung zu einem unsichtbaren Baustein der laufenden Shop-Wartung macht.
Das Wichtigste in Kürze
- Das CA/Browser-Forum senkt mit Ballot SC-081v3 die maximale Zertifikatslaufzeit in drei Stufen: ab 15. März 2026 auf 200 Tage, ab 15. März 2027 auf 100 Tage und ab 15. März 2029 auf 47 Tage (CA/Browser-Forum). Heute sind es noch 398 Tage (CA/Browser-Forum).
- Aus einer jährlichen Routine wird damit ein Vorgang, der 2029 alle sechs bis sieben Wochen ansteht -- rund achtmal so oft wie heute. Bei dieser Frequenz ist eine manuelle Erneuerung über Kalendererinnerungen kaum noch verlässlich leistbar.
- Ein abgelaufenes Zertifikat ist kein schleichendes Problem, sondern ein sofortiger Totalausfall: Jeder gängige Browser blockiert den Zugang mit einer formatfüllenden Warnseite. Es gibt keine Teilfunktion und keinen Graubereich.
- Die tragfähige Antwort ist Automatisierung nach dem Standard ACME (RFC 8555, IETF): Ein täglich laufender Dienst prüft die Restlaufzeit, verlängert rechtzeitig, legt die Dateien am erwarteten Ort ab und lädt den Webserver ohne Ausfall neu.
- Automatisierung senkt das Risiko, beseitigt es aber nicht. Ein geändertes DNS-Token, ein Ratenlimit oder ein fehlgeschlagener Reload lassen die Erneuerung still scheitern -- deshalb gehört ein unabhängiges Ablauf-Monitoring zu jeder ACME-Einrichtung.
Warum die TLS-Laufzeit überhaupt sinkt
Hinter der Verkürzung steht ein sicherheitstechnischer Gedanke: Je kürzer ein Zertifikat gültig ist, desto kleiner ist das Zeitfenster, in dem ein gestohlener privater Schlüssel oder ein fälschlich ausgestelltes Zertifikat missbraucht werden kann. Die etablierten Rückrufmechanismen – Sperrlisten (CRL) und der Online-Statusdienst OCSP – gelten in der Praxis als unzuverlässig, weil Browser eine fehlende Sperrauskunft häufig stillschweigend übergehen. Kurze Laufzeiten wirken hier wie ein eingebauter Ablauf: Ein kompromittiertes Zertifikat verschwindet ohnehin bald von selbst. Google hatte diese Richtung mit dem Fahrplan 'Moving Forward, Together' bereits 2023 vorgezeichnet und eine Obergrenze von 90 Tagen (Google) ins Gespräch gebracht. Den formalen Antrag brachte Apple ein (Apple); angenommen wurde er im April 2025 im CA/Browser-Forum (CA/Browser-Forum).
Der wirtschaftliche Hintergrund macht die Sache dringlich. Der deutsche Online-Handel mit Verbrauchern setzte 2025 rund 83,1 Milliarden Euro (bevh) um, bei einem durchschnittlichen Bestellwert von 146,19 Euro (bevh). Jede Minute, in der ein Shop wegen eines abgelaufenen Zertifikats nicht erreichbar ist, kostet unmittelbar Umsatz und Vertrauen – und anders als bei einem trägen Server sehen Kunden hier keine langsame Seite, sondern eine rote Warnung, die vor der eigenen Domain warnt. Wie teuer ein solcher Ausfall wird, hängt vom Geschäftsmodell ab; die Größenordnung lässt sich mit den Ausfallkosten pro Stunde grob abschätzen.
Kurz erklärt: Was das CA/Browser-Forum beschlossen hat
Der Zeitplan: von 398 auf 47 Tage
Die Verkürzung erfolgt nicht auf einen Schlag, sondern in drei Stufen über gut drei Jahre. Das gibt Betreibern Zeit, ihre Prozesse umzustellen – aber nur, wenn sie jetzt damit beginnen. Die folgende Übersicht zeigt die Stichtage, die jeweils zulässige Höchstlaufzeit, die schrumpfende Wiederverwendung der Domain-Prüfung und die Zahl der Erneuerungen, die sich daraus pro Jahr und Zertifikat ergeben.
| Stichtag | Max. Laufzeit | DCV-Wiederverwendung | Erneuerungen pro Jahr |
|---|---|---|---|
| Heute (seit 2020) | 398 Tage | 398 Tage | rund 1 |
| ab 15. März 2026 | 200 Tage | 200 Tage | rund 2 |
| ab 15. März 2027 | 100 Tage | 100 Tage | rund 4 |
| ab 15. März 2029 | 47 Tage | 10 Tage | bis zu 8 |
Die letzte Spalte ist der eigentliche Sprengstoff. Aus einer jährlichen Routine wird ein Vorgang, der 2029 alle sechs bis sieben Wochen ansteht – rund achtmal so oft wie heute. Zertifizierungsstellen wie DigiCert und Sectigo ziehen daraus denselben Schluss: Bei dieser Frequenz ist manuelle Erneuerung kaum noch verlässlich leistbar (DigiCert; Sectigo). Wer mehrere Domains, Subdomains und Testumgebungen betreibt, multipliziert den Aufwand zusätzlich. Ein Prozess mit Kalendererinnerung und Copy-and-paste skaliert an dieser Stelle nicht mehr mit.
Was passiert, wenn ein Zertifikat abläuft
Anders als viele Wartungsversäumnisse ist ein abgelaufenes TLS-Zertifikat kein schleichendes Problem, sondern ein sofortiger Totalausfall. In dem Moment, in dem die Gültigkeit endet, zeigt jeder gängige Browser eine formatfüllende Warnseite – etwa mit der Meldung NET::ERR_CERT_DATE_INVALID – und blockiert den Zugang. Der Shop ist technisch weiter online, für Kunden aber praktisch unerreichbar: Der Bezahlvorgang bricht ab, Suchmaschinen-Crawler stoßen auf Fehler, und in Preisvergleichen oder Anzeigen verlinkte Seiten führen ins Leere. Ein abgelaufenes Zertifikat wirkt damit wie ein ungeplanter Ausfall, nur mit dem Zusatz, dass die Fehlermeldung ausdrücklich vor der Seite warnt und so das Vertrauen zusätzlich beschädigt.
Kein Graubereich, sondern Aus
ACME: Automatisierung statt Kalendererinnerung
Die Antwort auf kürzere Laufzeiten ist keine engmaschigere Erinnerungsliste, sondern die vollständige Automatisierung der Erneuerung. Der Industriestandard dafür ist ACME (Automatic Certificate Management Environment), spezifiziert in RFC 8555 (IETF). Über dieses Protokoll weist ein Server der Zertifizierungsstelle selbstständig nach, dass er die Domain kontrolliert, fordert ein neues Zertifikat an und bekommt es ausgeliefert – ohne dass ein Mensch eingreift. Bekannt geworden ist der Ansatz durch die kostenlose Zertifizierungsstelle Let's Encrypt, die schon heute nur 90 Tage (Let's Encrypt) gültige Zertifikate ausstellt und die Erneuerung nach 60 Tagen (Let's Encrypt) empfiehlt. Wer dort bereits automatisiert erneuert, hat die 47-Tage-Zukunft im Grunde vorweggenommen.
Der entscheidende Punkt: Bei kurzen Laufzeiten ist Automatisierung nicht die bequeme, sondern die einzig tragfähige Option. Ein Prozess, der alle sechs Wochen ohne Aussetzer von Hand ausgeführt werden müsste, wird über Monate hinweg zwangsläufig einmal vergessen – im Urlaub, bei einem Personalwechsel oder im Tagesgeschäft. Eine ACME-Automatisierung dagegen läuft als Hintergrunddienst, prüft täglich die Restlaufzeit und erneuert rechtzeitig vor Ablauf. Damit verschiebt sich die Wartungsaufgabe von 'rechtzeitig daran denken' zu 'überwachen, dass die Automatik läuft' – eine deutlich robustere Fehlerklasse.
ACME-Client
Ein etablierter ACME-Client fordert Zertifikate automatisch an, weist die Domain-Kontrolle nach und legt die erneuerten Dateien am richtigen Ort ab.
Challenge-Verfahren
Die Domain-Prüfung läuft per HTTP-01 über eine Datei im Webroot oder per DNS-01 über einen TXT-Eintrag – Letzteres auch für Wildcard-Zertifikate.
Reload-Hook
Nach jeder Erneuerung lädt ein Hook den Webserver neu, damit das frische Zertifikat ohne manuellen Neustart und ohne Verbindungsabbruch aktiv wird.
Ablauf-Monitoring
Ein unabhängiger Wächter misst die Restlaufzeit von außen und schlägt Alarm, falls die Automatik trotz allem einmal nicht greift.
Staging-Test
Erstläufe werden gegen die Test-Endpunkte der Zertifizierungsstelle geprüft, bevor sie produktiv laufen, um Ratenlimits und Fehlkonfiguration zu vermeiden.
Protokoll
Jede Ausstellung wird mit Zeitpunkt, Gültigkeit und Seriennummer dokumentiert, damit der Zertifikatsbestand jederzeit nachvollziehbar bleibt.
Warum manuelle Prozesse jetzt kippen
Was die Umstellung im Shop konkret bedeutet
Für einen typischen Shopware- oder WordPress-Shop ist der Weg zur automatischen Erneuerung überschaubar, erfordert aber Sorgfalt an den Übergabestellen. Der ACME-Client muss nicht nur ein neues Zertifikat holen, sondern es auch dorthin legen, wo der Webserver es erwartet, und den Dienst sauber neu laden. Fehlt der Reload-Hook, liegt zwar ein gültiges Zertifikat auf der Platte, ausgeliefert wird aber weiterhin das alte – bis es abläuft. Solche stillen Lücken sind der häufigste Grund, warum eine vermeintlich automatische Einrichtung am Ende doch in einen Ausfall läuft.
- Bestandsaufnahme: alle Domains, Subdomains, Redirect-Hosts und Testumgebungen erfassen, die ein Zertifikat brauchen.
- ACME-Client einrichten und das passende Challenge-Verfahren wählen – HTTP-01 für einzelne Hosts, DNS-01 für Wildcards.
- Erneuerung als geplanten Hintergrunddienst hinterlegen, der täglich prüft und rechtzeitig vor Ablauf verlängert.
- Reload-Hook einrichten, der Webserver oder Load Balancer nach der Erneuerung ohne Verbindungsabbruch neu lädt.
- Ablauf-Monitoring von außen aufsetzen, das unabhängig von der Automatik alarmiert.
- Erstlauf in einer Testumgebung gegen die Staging-Endpunkte der Zertifizierungsstelle absichern, dann produktiv schalten.
# Täglicher Erneuerungslauf per Cron oder systemd-Timer
# Der Client prüft die Restlaufzeit und verlängert nur, wenn nötig
# /etc/cron.d/acme-renew
0 3 * * * root acme.sh --cron --home /etc/acme >> /var/log/acme.log 2>&1
# Reload-Hook: Webserver nach erfolgreicher Erneuerung neu laden
# --reloadcmd "systemctl reload nginx"
# Unabhängige Kontrolle der Restlaufzeit von außen
echo | openssl s_client -connect ihr-shop.de:443 2>/dev/null \
| openssl x509 -noout -enddateDer Ablauf oben ist bewusst schematisch – die konkrete Umsetzung hängt von Serverumgebung, Webserver und Hosting ab. Wichtig ist das Muster: ein täglich laufender Dienst, ein Reload ohne Ausfall und eine unabhängige Kontrolle. Genau dieses Zusammenspiel unterscheidet eine belastbare Automatisierung von einem Skript, das im Zweifel still versagt. In einem verwalteten Vertrag mit Sicherheitsupdates und Härtung gehört die Zertifikatspflege zu den Aufgaben, die im Hintergrund mitlaufen, ohne dass der Betreiber sich um Fristen kümmern muss.
Sonderfälle: Wildcard, viele Domains, Load Balancer
Nicht jeder Shop besteht aus einer einzigen Domain mit einem einzigen Server. Sobald Wildcard-Zertifikate, mehrere Second-Level-Domains, ein Content-Delivery-Setup oder ein Load Balancer im Spiel sind, verzweigt sich die Automatisierung. Wildcard-Zertifikate – etwa für alle Subdomains einer Marke – lassen sich nur über die DNS-01-Challenge erneuern, was einen programmierbaren Zugriff auf die DNS-Zone voraussetzt. Dieser Punkt hängt eng mit der Pflege von DNS und DNSSEC zusammen. Verteilt ein Load Balancer den Verkehr auf mehrere Knoten, muss das erneuerte Zertifikat auf allen Knoten synchron ankommen, bevor der alte Stand außer Kraft tritt.
- Wildcard-Zertifikate über DNS-01 mit programmierbarem Zugriff auf die DNS-Zone erneuern.
- Bei mehreren Knoten hinter einem Load Balancer das neue Zertifikat synchron verteilen.
- Auslaufende Zertifikate von unterschiedlichen Anbietern auf einen einheitlichen ACME-Prozess umstellen.
- Ratenlimits der Zertifizierungsstelle beachten und Erstläufe gegen Staging-Endpunkte testen.
- Interne Dienste und Testumgebungen nicht vergessen – auch sie laufen künftig mit kurzen Laufzeiten.
- Kontaktadresse für Ablaufwarnungen der Zertifizierungsstelle aktuell halten.
Monitoring: das zweite Netz unter der Automatik
Automatisierung senkt das Risiko, beseitigt es aber nicht vollständig. Ein geänderter DNS-Eintrag, ein abgelaufenes API-Token für die DNS-Challenge, ein Ratenlimit oder ein fehlgeschlagener Reload können dazu führen, dass die Erneuerung im Stillen scheitert. Deshalb gehört zu jeder ernsthaften ACME-Einrichtung ein unabhängiges Ablauf-Monitoring, das die Restlaufzeit von außen misst – so, wie ein Uptime-Monitoring die Erreichbarkeit überwacht. Schlägt der Wächter zum Beispiel 20 Tage vor Ablauf Alarm, bleibt genug Zeit, die Ursache zu finden, bevor Kunden je eine Warnung sehen. Diese Trennung von handelndem und kontrollierendem System ist der Kern jeder verlässlichen Wartung.
Die Zertifikatspflege steht dabei nicht für sich. Sie ist Teil einer laufenden technischen Hygiene, zu der auch der Schutz von Kundenkonten vor automatisierten Übernahmeversuchen und der Umgang mit der wachsenden Last durch KI-Crawler gehören. Alle drei Themen teilen denselben Kern: Ein Shop ist ein System, das sich unter Beobachtung verändert, und dessen Randbedingungen – Zertifikatslaufzeiten, Angriffsmuster, Zugriffsvolumen – sich unabhängig vom Betreiber verschieben. Wartung heißt, diese Verschiebungen früh zu bemerken und automatisiert darauf zu reagieren.
Kurze Zertifikatslaufzeiten bestrafen jeden manuellen Prozess und belohnen jede saubere Automatisierung. Die eigentliche Umstellung ist keine technische, sondern eine organisatorische: weg vom Termin im Kalender, hin zum überwachten Dienst.
So nehmen wir TLS in die laufende Wartung auf
In unseren Wartungspaketen ist die Zertifikatspflege ein fester, wiederkehrender Baustein – eng verzahnt mit Sicherheitsupdates, Monitoring und Backups. Am Anfang steht eine Bestandsaufnahme: Welche Domains und Subdomains sind im Einsatz, welche Zertifikate laufen wann aus, und wie werden sie heute erneuert? Auf dieser Grundlage richten wir die ACME-Automatisierung ein, hinterlegen Reload-Hooks für den jeweiligen Webserver und setzen ein unabhängiges Ablauf-Monitoring darüber. Die Umstellung erfolgt kontrolliert, damit zu keinem Zeitpunkt ein Zertifikat zwischen altem und neuem Prozess durchrutscht.
Für Shops, die bereits eine systematische Zertifikatsverwaltung betreiben, ist der Schritt zu 47 Tagen vor allem eine Frage der Frequenz und der Überwachung. Für Betreiber, die bisher jährlich von Hand erneuert haben, ist es der richtige Zeitpunkt, den Prozess grundlegend umzustellen – lange vor dem ersten Stichtag im März 2026. Wie der passende Umfang für einen konkreten Shop aussieht, lässt sich in einer kurzen Bestandsaufnahme klären; eine solche Analyse können Sie unverbindlich anfragen.