SSL-Automation: Drei Risiken der 200-Tage-Regel

Am 1. Oktober 2026 laufen die ersten SSL-Zertifikate mit der neuen Maximallaufzeit von 200 Tagen aus. Damit endet eine zwanzigjährige Routine, in der ein Zertifikat einmal jährlich erneuert werden musste.

Das CA/Browser Forum hat die schrittweise Verkürzung beschlossen: 200 Tage seit März 2026, 100 Tage ab März 2027, 47 Tage ab März 2029. Für Unternehmen mit verteilten Domain-Portfolios ist das eine operative Zäsur, die in vielen IT-Abteilungen bislang unterschätzt wird.

Drei Risiken, die IT Abteilungen berücksichtigen sollten, weil sie nicht nur die Technik betreffen, sondern auch Reputation, Personalplanung und Sicherheits-Architektur betreffen.

Risiko 1: Reputationsschaden durch ausgelaufene Zertifikate

Ein abgelaufenes SSL-Zertifikat ist kein stiller Ausfall. Browser zeigen Warnseiten mit hohen Abbruchraten, das Ranking in Google und Bing bricht ein, Kunden brechen Käufe ab, Zulieferer fragen nach. Die öffentliche Botschaft lautet: Hier wird die Sicherheits-Hygiene vernachlässigt. Mit der Verdopplung der Renewal-Frequenz ab Oktober steigt die statistische Wahrscheinlichkeit, dass selbst etablierte manuelle Routinen einmal stolpern. In den vergangenen Jahren haben Branchen wie Banking und E-Commerce öffentlich gewordene Ausfälle erlebt, deren Ursache nichts anderes war als ein vergessenes Zertifikat.

Es braucht daher Software-Konzepte, die den Verlängerungsprozess vollständig automatisieren. Was technisch lösbar ist, sollte nicht von Excel-Tabellen und Kalender-Erinnerungen abhängen. Die ACME-Standardisierung (RFC 8555) hat die Grundlage dafür geschaffen, aber sie greift nur, wenn sie in eine vollständige Lifecycle-Architektur eingebettet ist.

Risiko 2: Die unterschätzte Aufwandsfalle

Die meisten Unternehmen unterschätzen, wie schnell die Verkürzungskette zum personellen Problem wird. Wer heute hundert Zertifikate manuell betreut, kommt 2029 auf rund 800 Verlängerungen pro Jahr. Selbst bei einer optimistischen Bearbeitungszeit von 15 Minuten pro Zertifikat – inklusive Bestellung, Validierung, Installation und Dokumentation – ergibt das 200 Arbeitsstunden, also rund 25 Manntage pro Jahr. Nur für das Verlängern von SSL-Zertifikaten. Das entspricht rund fünf volle Arbeitswochen oder, anders gerechnet, einem ganzen Personenmonat, der ausschließlich für Renewals draufgeht. Wer 1.000 Zertifikate betreut, kommt entsprechend auf rund 250 Manntage – also mehr als einen Vollzeit-Mitarbeiter, der das ganze Jahr nichts anderes tut.

Bisher sind nur wenige Unternehmen wirklich vorbereitet. In unserer Beratungspraxis sehen wir eine kleine Spitzengruppe mit zentraler Plattform und vollautomatisierten Renewals, daneben eine breite Mitte mit halb automatisierten Mischlandschaften und eine nennenswerte Restgruppe, die nach wie vor mit Excel-Sheets und Kalender-Erinnerungen arbeitet. Es braucht daher Automatisierungslösungen für den gesamten SSL-Lifecycle, die flexibel genug sind, unterschiedliche Setups zu adressieren: vom homogenen Web-Server-Cluster über Hardware-Appliances und Legacy-Anwendungen bis hin zu einer Multi-CA-Strategie mit OV-, EV- und DV-Zertifikaten parallel.

Risiko 3: Sicherheitslücken im Eigenbau

Die meisten Eigenbau-ACME-Setups haben eine strukturelle Schwachstelle, die im Tagesgeschäft oft übersehen wird. Der ACME-Client erhält direkte Schreibrechte auf die produktive DNS-Zone, weil die DNS-01-Challenge in Unternehmensumgebungen die übliche Validierungsmethode ist – nur sie erlaubt Wildcard-Zertifikate und funktioniert auch für interne Hosts. Wird das API-Token kompromittiert, kann ein Angreifer im Worst Case nicht nur Validierungs-Einträge, sondern auch DNSSEC-Signaturen, MX-Records, SPF- und DKIM-Einträge manipulieren. Damit stehen genau die Mechanismen offen, die Mail-Spoofing und Phishing eigentlich verhindern sollen.

Das BSI weist im IT-Grundschutz-Kompendium explizit auf die Risiken unzureichend abgesicherter DNS-Update-Pfade hin. In stark regulierten Branchen wie Banken, Versicherungen oder KRITIS-Betreibern wird der Punkt zunehmend in Audits abgefragt. Mit der NIS2-Umsetzung rückt das Thema zusätzlich in den Fokus interner Prüfpflichten.

Die architektonische Antwort heißt CNAME-Delegation, in der Praxis oft als DCV-Zonen-Konzept bezeichnet. Statt dem ACME-Client Schreibrechte auf die produktive DNS-Zone zu geben, wird der _acme-challenge-Subnamespace per CNAME auf eine dedizierte Validierungs-Zone umgeleitet. Alle Validierungseinträge passieren ausschließlich dort. Selbst bei kompromittiertem Token bleibt die Hauptzone strukturell unerreichbar. Moderne Lifecycle-Lösungen sollten diese Trennung architektonisch erzwingen, nicht optional anbieten.

Was eine moderne Lifecycle-Lösung leisten muss

Aus den drei Risiken ergeben sich konkrete Anforderungen an eine zukunftsfähige Architektur. Erstens: Multi-CA-Fähigkeit ohne Re-Implementierung. Die vergangenen Jahre haben gezeigt, dass selbst große Certificate Authorities binnen Tagen Vertrauen verlieren können. Ein Wechsel muss ohne Endsystem-Anpassungen möglich sein. Zweitens: strukturell erzwungene DCV-Trennung, sodass produktive DNS-Zonen niemals schreibend berührt werden. Drittens: eine API-Alternative für Setups ohne ACME-Stack, etwa Legacy-Anwendungen, Multi-Tenant-Plattformen oder Custom-CertOps-Tooling. Viertens: ein zentrales Inventar mit lückenlosem Audit-Trail, das ISO 27001, NIS2 und DORA tragfähig abbildet.

Diese vier Punkte sind die Mindestanforderungen einer Lifecycle-Plattform. Sie skalieren nicht nur auf die 200-Tage-Regel, sondern auch auf die kommenden Verkürzungen 2027 und 2029. Und sie tragen perspektivisch in die Post-Quantum-Migration hinein, deren erste Standards das NIST im August 2024 finalisiert hat.

Vom Stichtag zur Routine

Der 1. Oktober 2026 ist kein Endpunkt, sondern der zweite Schritt einer mehrjährigen Verkürzungskette. Wer das Thema isoliert als Stichtag behandelt, baut Prozesse, die im Folgejahr wieder nachjustiert werden müssen. Wer dagegen die Verkürzung als strategischen Anlass nimmt, eine vollwertige Lifecycle-Architektur einzuführen, gewinnt einen mehrjährigen Vorsprung. Sowohl in der operativen Stabilität als auch in der Bilanz gegenüber Audits und Compliance-Anforderungen.

Die einzige nicht-tragfähige Option ist, gar nichts zu tun.

Thomas Küchenthal, Gründer und Chief Technology Officer (CTO) der LEMARIT GmbH