7 Min. Lesezeit

Ab dem 15. März 2026 dürfen TLS-Zertifikate nur noch 200 Tage gültig sein. 2027 folgen 100 Tage, 2029 die finale 47-Tage-Grenze. Wer heute 1.000 Zertifikate manuell verwaltet, steht vor einem Betriebsproblem: 48.000 Stunden Verwaltungsaufwand pro Jahr bis 2029. Ohne Automatisierung wird Certificate Management zum Dauerbrandherd.

Das Wichtigste in Kürze

• Ab 15. März 2026 gilt: Maximale TLS-Laufzeit 200 Tage. 2027: 100 Tage. 2029: 47 Tage.
• 72 Prozent der Unternehmen hatten 2025 mindestens einen Zertifikats-Ausfall (Venafi, 2025).
• 47-Tage-Grenze bedeutet 8-mal mehr Renewal-Workload als heute. Manuell nicht machbar.
• Ballot SC081v3 des CA/Browser Forums ist beschlossen. Kein „Falls“, sondern „Wann“.
• Let’s Encrypt, DigiCert und Sectigo bieten ACME-basierte Automation als Sofortlösung.

Warum kürzere Zertifikate ein Betriebsrisiko sind

TLS-Zertifikate sind unsichtbar, bis sie ablaufen. Dann wird aus einem technischen Detail ein Geschäftsvorfall: Webseiten zeigen Sicherheitswarnungen, APIs liefern 502-Fehler, Kunden sehen „Verbindung nicht sicher“. Im September 2021 legte ein abgelaufenes Zertifikat das gesamte Facebook-Netzwerk für sechs Stunden lahm. Die Kosten: geschätzt 59,8 Millionen Euro Umsatzausfall.

Der State of Machine Identity Report 2025 von Venafi zeigt: 72 Prozent aller Unternehmen hatten im vergangenen Jahr mindestens einen Vorfall durch ein abgelaufenes oder falsch konfiguriertes Zertifikat. Die Hauptursache: manuelle Verwaltung in Tabellen statt automatisiertem Lifecycle Management.

Mit der neuen 200-Tage-Grenze ab März 2026 verschärft sich das Problem massiv. Ein Unternehmen mit 500 Zertifikaten muss diese künftig fast doppelt so oft erneuern wie bisher. Bei der 47-Tage-Grenze ab 2029 sind es acht Mal so viele Renewals. Ohne Automatisierung ist das schlicht nicht leistbar.

„Die Verkürzung der Zertifikatslaufzeiten ist keine Bestrafung der IT-Teams. Sie ist eine Antwort auf die Realität: Kompromittierte Zertifikate müssen schneller aus dem Verkehr gezogen werden können.“

Sinngemäß nach DigiCert Blog (2025)

Der Fahrplan: Von 200 auf 47 Tage in drei Stufen

Das CA/Browser Forum hat mit Ballot SC081v3 einen verbindlichen Stufenplan beschlossen:

Stufe 1 (15. März 2026): Maximale Laufzeit 200 Tage. Für die meisten Unternehmen spürbar, aber mit bestehenden Prozessen noch machbar.

Stufe 2 (15. März 2027): Maximale Laufzeit 100 Tage. Ab hier wird manuelle Verwaltung zum Vollzeit-Job. Quartalsweise Renewals für das gesamte Portfolio.

Stufe 3 (15. März 2029): Maximale Laufzeit 47 Tage. Monatliche Renewals. Nur mit vollständiger Automatisierung realisierbar.

Automated Certificate Lifecycle Management: Die drei Optionen

Option 1: ACME-Protokoll (Let’s Encrypt Modell). Das Automatic Certificate Management Environment (ACME) ist der De-facto-Standard für automatisierte Zertifikatsverwaltung. Let’s Encrypt nutzt es seit 2016 erfolgreich. Certbot, LEGO und andere Clients automatisieren Beantragung, Validierung und Erneürung komplett. Kosten: Null (bei Let’s Encrypt) bis minimal. Einschränkung: Nur Domain-Validated (DV) Zertifikate, keine Extended Validation.

Option 2: Kommerzielle CLM-Plattformen. DigiCert CertCentral, Sectigo Certificate Manager, Venafi Trust Protection Platform. Diese Lösungen verwalten das gesamte Zertifikatsportfolio zentral: Discovery, Monitoring, Renewal, Revocation. Kosten: Ab circa 5.000 Euro pro Jahr für mittelständische Umgebungen. Vorteil: OV/EV-Zertifikate, Multi-CA-Support, Compliance-Reporting.

Option 3: Cloud-native Ansätze. AWS Certificate Manager, Azure Key Vault, Google Certificate Manager. Wenn Ihre Infrastruktur bereits in einer Cloud läuft, ist dies der einfachste Weg: Zertifikate werden automatisch erstellt, erneuert und auf Load Balancern deployed. Einschränkung: Funktioniert nur innerhalb des jeweiligen Cloud-Ökosystems.

Die Gegenposition: Warum manche CIOs abwarten

Nicht jeder IT-Leiter sieht die Dringlichkeit. Das Argument: Die 200-Tage-Grenze ist noch handhabbar, die 47-Tage-Grenze liegt drei Jahre in der Zukunft. Warum jetzt investieren? Die Antwort ist einfach: Weil die Migration zu automatisiertem Certificate Management selbst 6 bis 12 Monate dauert. Wer erst 2028 anfängt, hat weniger als ein Jahr bis zur 47-Tage-Deadline. Und jeder Zertifikats-Ausfall in der Zwischenzeit kostet mehr als die Automatisierung.

Drei Schritte für die nächsten 90 Tage

Schritt 1: Zertifikats-Inventar erstellen (Woche 1-2). Wie viele Zertifikate haben Sie? Wo laufen sie? Wann laufen sie ab? Tools wie Venafi, Keyfactor oder sogar OpenSSL-Scripts können das automatisiert scannen. Das Ergebnis ist oft eine Überraschung: Viele Unternehmen finden 2 bis 3 Mal mehr Zertifikate als erwartet.

Schritt 2: Automation-Strategie wählen (Woche 3-4). ACME für einfache Szenarien, kommerzielle CLM für komplexe Umgebungen, Cloud-native für Cloud-Only-Setups. Für die meisten DACH-Mittelständler ist eine Kombination aus ACME (für Web-Server) und kommerzieller CLM (für interne Dienste) der pragmatische Weg.

Schritt 3: Pilot mit den kritischsten Systemen (Monat 2-3). Beginnen Sie nicht mit allem auf einmal. Identifizieren Sie die 10 Zertifikate deren Ablauf den größten Schaden verursachen würde. Automatisieren Sie deren Lifecycle als Proof of Concept. Dann skalieren.

Fazit: 47 Tage kommen schneller als man denkt

Die Verkürzung der TLS-Laufzeiten ist beschlossene Sache. Die Frage ist nicht ob, sondern wie schnell Sie automatisieren. Die 200-Tage-Grenze ab März 2026 ist der Weckruf. Wer jetzt sein Zertifikats-Inventar erstellt und eine Automation-Strategie wählt, hat drei Jahre Zeit für eine geordnete Migration. Wer wartet, baut ein wachsendes Ausfallrisiko auf. Die Kosten eines einzigen Zertifikats-Ausfalls übersteigen die Investition in CLM-Automation um ein Vielfaches.

Häufige Fragen

Betrifft die 200-Tage-Regel auch interne Zertifikate oder nur öffentliche?

Die Ballot SC081v3 des CA/Browser Forums betrifft direkt nur öffentlich vertrauenswürdige TLS-Zertifikate (von CAs wie DigiCert, Let’s Encrypt, Sectigo). Interne Zertifikate (von einer Private CA) sind nicht direkt betroffen. Allerdings empfehlen Sicherheitsexperten, auch interne Zertifikate kürzer zu halten, da kompromittierte interne Zertifikate ein ebenso großes Risiko darstellen.

Wir nutzen Wildcard-Zertifikate. Ändert sich etwas?

Ja, Wildcard-Zertifikate unterliegen denselben Laufzeit-Regeln. Ab März 2026 maximal 200 Tage, ab 2029 maximal 47 Tage. Wildcard-Zertifikate haben ein höheres Risikoprofil: Ein kompromittiertes Wildcard-Zertifikat betrifft alle Subdomains. Die kürzere Laufzeit reduziert dieses Fenster. Automatisierung ist hier besonders wichtig.

Was kostet die Umstellung auf automatisiertes Certificate Management?

ACME mit Let’s Encrypt ist kostenlos (nur Implementierungsaufwand: 1-2 Tage pro Server-Typ). Kommerzielle CLM-Plattformen starten bei circa 5.000 Euro pro Jahr für 100 bis 500 Zertifikate. Enterprise-Lösungen (Venafi, Keyfactor) kosten 20.000 bis 50.000 Euro pro Jahr. Dem gegenüber stehen die Kosten eines Ausfalls: Im Schnitt 300.000 Euro pro Zertifikats-Vorfall laut Ponemon Institute.

Können wir nicht einfach bei unserem bestehenden CA-Anbieter bleiben?

Ja, aber nur wenn er ACME unterstützt. DigiCert, Sectigo, GlobalSign und die meisten großen CAs bieten ACME-Endpunkte. Prüfen Sie ob Ihr aktueller Anbieter Automated Lifecycle Management als Feature hat. Wenn nicht, ist der Wechsel zu einem CLM-fähigen Anbieter die bessere Investition als manuelle Prozesse beizubehalten.

Wie erkennen wir ob ein Zertifikat bald abläuft bevor es zum Ausfall kommt?

Monitoring-Tools wie Nagios, Datadog oder spezialisierte Certificate-Monitoring-Dienste (SSLMate, CertSpotter) können ablaufende Zertifikate Wochen vorher erkennen. Als Sofortmaßnahme: Ein einfaches Bash-Script mit openssl s_client, das täglich alle externen Endpunkte prüft und bei Restlaufzeit unter 30 Tagen alarmiert. Das kostet nichts und verhindert die schlimmsten Ausfälle.

Weiterführende Lektüre im Netzwerk

• Cloud-native Identity: OAuth 2.1, Passkeys und die Zukunft der Authentifizierung (cloudmagazin)
• SaaS-Krise 2026: Warum Salesforce 26 Prozent verliert (cloudmagazin)

Mehr aus dem MBF Media Netzwerk

• API-Sicherheit: 5 Schritte zur Schnittstellenstrategie (SecurityToday)
• Sovereign Cloud als Board-Entscheidung (Digital Chiefs)

Quelle Titelbild: Pexels