Zum Inhalt springen
Wiesbaden · Rhein-Main · Remote nach Vereinbarung IT-Wissen Unternehmen Kontakt

TLS-Zertifikate 2026: Warum 200 Tage Laufzeit jetzt Automatisierung erzwingen

Seit März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate maximal 200 Tage gültig sein. Warum Unternehmen ACME, Inventarisierung und automatisierte Erneuerung jetzt ernst nehmen müssen.

Stand: 30. September 2026

Die Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate wird deutlich kürzer. Seit dem 15. März 2026 begrenzen die Baseline Requirements des CA/Browser Forum die maximale Gültigkeit von Subscriber-Zertifikaten auf 200 Tage. Das ist mehr als eine formale Änderung: Für Unternehmen wird manuelles Zertifikatsmanagement damit zunehmend unpraktisch.

Wer bisher einmal pro Jahr eine Excel-Liste geprüft und Zertifikate manuell ausgetauscht hat, braucht einen moderneren Prozess. Je kürzer die Laufzeiten werden, desto häufiger entstehen Renewals, Freigaben, Deployments und potenzielle Ausfälle. Die eigentliche Antwort lautet deshalb nicht „mehr Erinnerungen“, sondern Certificate Lifecycle Automation.

Warum kürzere Zertifikatslaufzeiten sinnvoll sind

Ein Zertifikat bindet einen öffentlichen Schlüssel an eine Identität. Wenn Schlüssel kompromittiert werden oder Validierungsdaten veralten, begrenzt eine kurze Zertifikatslaufzeit das Zeitfenster, in dem ein altes Zertifikat weiterverwendet werden kann. Gleichzeitig zwingt die kürzere Laufzeit Betreiber dazu, ihre Prozesse zu automatisieren und Altbestände sichtbar zu machen.

Die neue 200-Tage-Grenze

Das CA/Browser Forum hat die maximale Gültigkeit öffentlich vertrauenswürdiger TLS-Zertifikate 2026 auf 200 Tage reduziert. Zusätzlich verkürzen sich Wiederverwendungszeiträume für Domain- und IP-Validierungsdaten. Damit steigt die operative Frequenz im gesamten Zertifikatsprozess.

Die Entwicklung geht weiter. Unternehmen sollten daher Systeme so bauen, dass eine weitere Verkürzung keine neue Großmigration auslöst. Wer heute auf Automatisierung setzt, ist für künftige Laufzeiten deutlich besser vorbereitet.

Welche Systeme häufig vergessen werden

Webserver sind nur der sichtbare Teil. Zertifikate liegen außerdem auf Reverse Proxies, Load Balancern, Firewalls, VPN-Gateways, Appliances, API-Gateways, Kubernetes Ingress Controllern, Monitoring-Systemen, Mailservern und internen Verwaltungsoberflächen.

Besonders kritisch sind Zertifikate, deren Ablauf niemand aktiv überwacht. Ein einziges abgelaufenes Zertifikat kann API-Verbindungen, SSO, Monitoring, Mailflow oder eine komplette Kundenanwendung unterbrechen.

ACME statt manueller Erneuerung

Das ACME-Protokoll hat sich als Standard für automatisierte Ausstellung und Erneuerung etabliert. Der große Vorteil liegt nicht nur darin, dass ein Zertifikat automatisch verlängert wird. ACME schafft einen wiederholbaren Prozess, der sich in Webserver, Load Balancer, Kubernetes, Reverse Proxies und andere Plattformen integrieren lässt.

Unternehmen sollten dabei interne und externe PKI getrennt betrachten. Öffentliche Zertifikate können häufig direkt über ACME automatisiert werden. Für interne Zertifikate kann eine eigene PKI mit automatisierten Enrollment-Prozessen sinnvoll sein.

Zertifikatsinventar wird zur Pflicht

Bevor automatisiert werden kann, muss bekannt sein, welche Zertifikate existieren. Ein gutes Inventar erfasst Subject, SANs, Issuer, Laufzeit, Fingerprint, privaten Schlüssel, verantwortliches System, Besitzer, Renewal-Methode und Deployment-Ziel.

Dieser Gedanke ist eng mit Post-Quantum Security 2026 verbunden: Wer seine Kryptografie nicht inventarisiert, kann weder Laufzeiten noch Algorithmen kontrolliert migrieren.

Monitoring: Ablaufdatum ist nur eine Kennzahl

Ein Zertifikatsmonitor sollte nicht nur warnen, wenn noch sieben Tage verbleiben. Sinnvoll sind mehrere Schwellenwerte, beispielsweise 60, 30, 14 und 7 Tage. Zusätzlich sollten Chain-Probleme, falsche Hostnamen, schwache Signaturalgorithmen und fehlgeschlagene Auto-Renewals erkannt werden.

Bei automatisierten Renewals sollte nach dem Austausch ein echter TLS-Handshake geprüft werden. Nur weil die neue Datei auf dem Server liegt, heißt das nicht, dass der Dienst sie geladen hat.

Private Keys und Berechtigungen

Automatisierung darf nicht dazu führen, dass private Schlüssel unkontrolliert verteilt werden. ACME-Clients, Service Accounts und Deployment-Jobs benötigen minimal notwendige Rechte. Secrets sollten verschlüsselt gespeichert und der Zugriff auditierbar sein.

Empfohlene Roadmap

Schritt 1: Alle öffentlich erreichbaren TLS-Endpunkte inventarisieren.

Schritt 2: Zertifikate nach Betreiber, CA und Erneuerungsmethode gruppieren.

Schritt 3: Manuelle Renewals zuerst bei geschäftskritischen Endpunkten automatisieren.

Schritt 4: ACME oder vergleichbare Enrollment-Prozesse standardisieren.

Schritt 5: Monitoring, Auto-Renewal und Deployment gemeinsam testen.

Schritt 6: Interne PKI und Machine Identities in denselben Lifecycle-Prozess aufnehmen.

Fazit

Die 200-Tage-Grenze 2026 ist ein deutlicher Hinweis: Zertifikatsmanagement entwickelt sich von einer gelegentlichen Admin-Aufgabe zu einem automatisierten Infrastrukturprozess. Unternehmen, die heute ein vollständiges Inventar, ACME, Monitoring und sichere Key-Verwaltung aufbauen, reduzieren nicht nur Ausfälle, sondern schaffen zugleich die Grundlage für moderne PKI- und Post-Quantum-Migrationen.

Weiterführende Quellen

CA/Browser Forum: Baseline Requirements

Titelbild: FlyD / Unsplash

Autor: Salman Dolatpanah Gortlar

Fragen zu Ihrer IT?

Wir übersetzen Technik in einen klaren nächsten Schritt.

Kontakt aufnehmen →