Von 200 auf 47 Tage: Wie lassen sich kürzere Laufzeiten von TLS-Zertifikaten effizient umsetzen?
TLS-Zertifikate kommen in nahezu jedem Unternehmen zum Einsatz. Sie bilden die Vertrauensbasis für verschlüsselte Verbindungen zu Websites, Applikationen, APIs und digitalen Services. Gleichzeitig verändern sich die Rahmenbedingungen für ihren Einsatz: Das CA/Browser Forum hat beschlossen, die maximal zulässige Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise zu verkürzen. Seit dem 15. März 2026 liegt sie bei maximal 200 Tagen, ab 2027 sind es nur noch 100 Tage und ab 2029 schließlich 47 Tage.
Dadurch müssen Unternehmen Zertifikate deutlich öfter beantragen, Domains validieren, neue Zertifikate bereitstellen und bestehende Installationen aktualisieren. Bei kürzeren Laufzeiten wird es immer schwieriger, Zertifikate zuverlässig über Kalendererinnerungen, Excel-Listen oder manuelle Tickets zu verwalten. Je kürzer die Laufzeiten werden, desto wichtiger wird ein durchgängiges Certificate Lifecycle Management, das Transparenz, klare Zuständigkeiten und automatisierte Abläufe miteinander verbindet.
Warum kürzere Laufzeiten von TLS-Zertifikaten das Betriebsrisiko erhöhen
Zertifikate hatten schon immer ein Ablaufdatum. Verändert hat sich die Geschwindigkeit, mit der der gesamte Prozess erneut durchlaufen werden muss. Bei einer langen Laufzeit konnte die Erneuerung öffentlich vertrauenswürdiger TLS-Zertifikate in den meisten Unternehmen als vergleichsweise seltene Administrationsaufgabe behandelt werden. Die neuen Vorgaben des CA/Browser Forum verändern diese Ausgangslage: Seit dem 15. März 2026 beträgt die maximale Laufzeit 200 Tage, ab dem 15. März 2027 noch 100 Tage und ab dem 15. März 2029 nur noch 47 Tage.
Mit jeder Verkürzung steigt die Zahl der Renewal-Vorgänge. Zusätzlich muss jeder einzelne zuverlässig funktionieren. Läuft ein Zertifikat unbemerkt ab, kann es zu Warnmeldungen, Verbindungsabbrüchen oder zur Nichterreichbarkeit eines Dienstes kommen. Die Zertifikatsverwaltung erhält damit unmittelbare Bedeutung für den stabilen IT-Betrieb, was weit mehr als PKI-Administratoren betrifft. Je nach Infrastruktur sind Operations-, Netzwerk-, Plattform- und Application-Teams beteiligt. Sie müssen gewährleisten, dass Zertifikate auf Webservern, Load Balancern, Cloud-Ressourcen, APIs oder Anwendungen zum richtigen Zeitpunkt korrekt ausgetauscht werden.
Die neuen Grenzwerte gelten für öffentlich vertrauenswürdige TLS-Serverzertifikate. Interne Zertifikate aus einer privaten Unternehmens-PKI sind davon nicht unmittelbar betroffen. Für den Betrieb ist es dennoch sinnvoll, öffentliche und private Zertifikate in einer übergreifenden Certificate-Lifecycle-Strategie zu berücksichtigen. So lassen sich Bestände, Verantwortlichkeiten und Prozesse zentral steuern. Zudem sollte die in die übergeordnete Sicherheitsarchitektur eingebunden werden.
Excel-Listen, Tickets und Erinnerungen reichen bald nicht mehr aus
Viele Betriebe verwalten Zertifikate weiterhin manuell oder teilweise automatisiert. Ablaufdaten stehen in Tabellen, Monitoring-Systeme oder Kalendereinträge erzeugen Erinnerungen und neue Zertifikate werden per Ticket beantragt. Anschließend laden Administratoren sie herunter und installieren sie auf den jeweiligen Zielsystemen.
Solange es wenige Zertifikate gibt und deren Laufzeiten lang sind, kann ein solcher Ablauf funktionieren. Mit 47 Tagen maximaler Gültigkeit steht rechnerisch ab 2029 etwa alle sechs bis sieben Wochen eine Erneuerung an. Ein Unternehmen mit einem größeren Zertifikatsbestand muss also parallel eine wesentlich höhere Zahl an Renewal-Prozessen koordinieren.
Zusätzlich wird die Domain- oder IP-Adressvalidierung anspruchsvoller. Ab dem 15. März 2029 kann eine bereits erfolgte Validierung nur noch zehn Tage wiederverwendet werden. Damit wächst nicht nur die Zahl der Zertifikatserneuerungen, auch die Validierungsprozesse müssen in wesentlich kürzeren Intervallen zuverlässig ablaufen, denn mit der Ausstellung endet ein Renewal nicht.
Das neue Zertifikat muss auf das richtige Zielsystem gelangen, gemeinsam mit der vollständigen Zertifikatskette aktiviert und anschließend technisch geprüft werden. Das bisherige Zertifikat muss kontrolliert ersetzt oder bei Bedarf widerrufen werden. Fehlt eine vollständige Bestandsübersicht, können Installationen auf Cloud-Ressourcen, dezentral administrierten Anwendungen oder wenig dokumentierten Systemen unbemerkt bleiben. Je mehr manuelle Übergaben in diesem Prozess liegen, desto größer werden administrativer Aufwand und Fehlerpotenzial. Zudem entsteht eine starke Abhängigkeit von einzelnen Personen und ihrem Wissen über die Infrastruktur.
Wie man die Erneuerung von TLS-Zertifikaten mithilfe des Certificate Lifecycle Management automatisiert
Eine belastbare Lösung beginnt damit, Certificate Renewal als durchgängigen Lebenszyklus zu behandeln. Dieser reicht von der Inventarisierung und Ausstellung über Bereitstellung und Erneuerung bis zu Monitoring und Widerruf.
1. Transparenz über den Zertifikatsbestand schaffen
Am Anfang steht die Frage: Welche Zertifikate sind überhaupt vorhanden?
Zu jedem Zertifikat sollten mindestens Laufzeit, Aussteller, Einsatzort, Status und Verantwortlichkeit zentral nachvollziehbar sein. Erst auf dieser Basis lässt sich erkennen, welche Systeme von kürzeren Laufzeiten betroffen sind und wo Handlungsbedarf besteht.
2. Regeln und Zertifikatsprozesse standardisieren
Auf dem Inventar bauen einheitliche Regeln für Ausstellung, Erneuerung und Widerruf auf. Zertifikatsprofile und Richtlinien reduzieren individuelle Sonderwege und schaffen einen reproduzierbaren Prozess.
Dazu gehört auch die Definition der Zuständigkeiten: Wer verantwortet das Zertifikat? Wer den dazugehörigen Service? Und was passiert, wenn eine automatisierte Erneuerung fehlschlägt?
3. Ausstellung und Erneuerung automatisieren
Wo die beteiligten Systeme es unterstützen, können standardisierte Protokolle wie ACME oder APIs genutzt werden. Damit lassen sich wiederkehrende Schritte automatisieren und manuelle Eingriffe reduzieren.
Automation sollte dabei über die reine Ausstellung hinausgehen. Ein neuer Zertifikatsdatensatz in einer CA hilft wenig, wenn das Zertifikat anschließend manuell auf mehreren Zielsystemen installiert werden muss.
4. Zertifikate automatisch bereitstellen und validieren
Nach der Ausstellung muss das Zertifikat auf den vorgesehenen Systemen installiert und aktiviert werden. Anschließend sollte eine technische Kontrolle bestätigen, dass der Dienst tatsächlich das neue Zertifikat mit der richtigen Zertifikatskette ausliefert.
Fehler bei diesem Schritt müssen sichtbar werden und einen definierten Eskalationsprozess auslösen.
5. Monitoring und Widerruf integrieren
Ein zentraler Lifecycle schafft dauerhafte Transparenz über Status, Ablaufdaten und fehlgeschlagene Abläufe. Ist ein Zertifikat kompromittiert, wird ein System außer Betrieb genommen oder darf ein Zertifikat aus anderen Gründen nicht länger eingesetzt werden, gehört auch der Widerruf zum gesteuerten Prozess.
So verschiebt sich Zertifikatsmanagement von einer reaktiven Aufgabe kurz vor dem Ablaufdatum zu einem kontinuierlich kontrollierten Betriebsprozess.
Vorteile eines automatisierten Zertifikats-Lifecycle-Management
Die Auswirkungen reichen von höherer Verfügbarkeit bis zu einer besseren Auditierbarkeit. Die Vorteile lassen sich so zusammenfassen:
| Vorteil | Wie wird er erreicht? | Nutzen für Unternehmen |
|---|---|---|
| Höhere Verfügbarkeit | Automatisierte Erneuerungen, konfigurierbare Vorlaufzeiten, Monitoring und Eskalationen | Das Risiko ungeplanter Serviceausfälle durch abgelaufene Zertifikate sinkt. |
| Weniger manueller Betriebsaufwand | Regelbasierte Workflows, ACME, APIs sowie die Integration von Zertifizierungsstellen und Zielsystemen | Größere Zertifikatsbestände lassen sich verwalten, ohne dass der Personalaufwand proportional zur Renewal-Frequenz steigt. |
| Zentrale Transparenz | Inventarisierung, Suchfunktionen, Monitoring, Cockpits und Berichte | Kritische Zertifikate werden frühzeitig sichtbar und können gezielt priorisiert werden. |
| Konsistente Sicherheitsrichtlinien | Zentrale Zertifikatsprofile, Richtlinien, rollenbasierte Prozesse und definierte Sicherheitsstufen | Fehlkonfigurationen und unkontrollierte Ausnahmen werden reduziert. |
| Bessere Auditierbarkeit | Dokumentierte Ausstellung, Erneuerung, Widerruf und administrative Eingriffe | Interne und externe Prüfer erhalten nachvollziehbare Informationen über Zertifikatsprozesse und Risikokontrollen. |
Praxisbeispiele für automatisiertes Certificate Lifecycle Management
Die Herausforderungen unterscheiden sich je nach Infrastruktur. Drei Szenarien zeigen, wie Certificate Lifecycle Management konkret eingesetzt werden kann.
Öffentlich erreichbare Websites, Kundenportale und APIs
Ein Unternehmen betreibt mehrere öffentliche Webanwendungen sowie APIs über Webserver und Load Balancer. Die dort eingesetzten öffentlich vertrauenswürdigen TLS-Zertifikate müssen künftig in wesentlich kürzeren Abständen ersetzt werden.
Ein automatisierter Prozess erkennt anstehende Ablaufdaten, beantragt ein neues Zertifikat, führt die erforderliche Domainvalidierung aus und verteilt das Ergebnis auf die betroffenen Systeme. Nach der Bereitstellung prüft der Prozess, ob der Service erreichbar ist und das korrekte Zertifikat verwendet.
Hybride IT- und Cloud-Infrastrukturen
In hybriden Umgebungen befinden sich Zertifikate beispielsweise in lokalen Rechenzentren, Cloud-Plattformen, auf Reverse Proxies und innerhalb containerisierter Anwendungen. Ohne gemeinsame Sicht können Einträge doppelt erfasst werden oder vollständig aus dem Blick geraten.
Ein zentraler Lebenszyklus führt die Bestände zusammen, ordnet Verantwortlichkeiten zu und bindet unterschiedliche Zielsysteme über geeignete Schnittstellen an. Damit entsteht eine gemeinsame Steuerungsebene über technisch verschiedene Umgebungen hinweg.
Öffentliche Verwaltung und kritische Infrastrukturen
Bei geschäftskritischen Diensten kommen hohe Anforderungen an Verfügbarkeit und Nachweisbarkeit zusammen. Kurze Laufzeiten würden bei manueller Verwaltung immer wieder operative Eingriffe notwendig machen. Automatisierte Erneuerungen, dokumentierte Freigaben und Reporting reduzieren manuelle Berührungspunkte und sorgen für nachvollziehbare Abläufe.
Wie gelingt die Umstellung auf automatisierte Zertifikats-Erneuerung?
Der Einstieg sollte mit einer strukturierten Bestandsaufnahme beginnen. Wer sofort einzelne Zertifikate automatisiert, ohne Zertifikatsbestand, Zuständigkeiten und Prozesse zu kennen, löst nur einen Teil des Problems.
1. Geltungsbereich definieren
Zunächst sollte feststehen, welche Zertifikatstypen und Umgebungen einbezogen werden. Dabei ist eine klare Trennung zwischen öffentlich vertrauenswürdigen TLS-Zertifikaten und internen Zertifikaten der Unternehmens-PKI sinnvoll.
2. Zertifikatsbestand erfassen
Bekannte Zertifikatsquellen, CAs und Zielsysteme werden in einem Inventar zusammengeführt. Zusätzlich sollte gezielt nach Zertifikaten gesucht werden, die außerhalb der dokumentierten Prozesse entstanden sind.
3. Owner und Kritikalität festlegen
Jedes Zertifikat benötigt einen technischen und gegebenenfalls fachlichen Owner. Parallel werden die zugehörigen Services nach Kritikalität, öffentlicher Erreichbarkeit und möglichen Auswirkungen eines Ausfalls bewertet.
4. Den gesamten Lifecycle standardisieren
Beantragung, Freigabe, Ausstellung, Verteilung, Erneuerung und Widerruf werden als zusammenhängender Ablauf definiert. Für notwendige Ausnahmen braucht es dokumentierte und zeitlich begrenzte Verfahren.
5. Automatisierung sinnvoll priorisieren
Für den Einstieg bieten sich öffentlich erreichbare, geschäftskritische oder regelmäßig zu erneuernde Zertifikate an. Systeme ohne geeignete Schnittstelle benötigen einen alternativen kontrollierten Prozess.
6. Pilotieren, Fehlerfälle testen und ausrollen
Statt sofort die gesamte Umgebung umzustellen, empfiehlt sich ein Pilotprojekt mit einer überschaubaren Zahl repräsentativer Systeme. Getestet wird nicht nur der erfolgreiche Renewal. Auch eine fehlgeschlagene Validierung, ein nicht erreichbares Zielsystem oder eine fehlerhafte Zertifikatskette sollten Bestandteil des Tests sein.
Kriterien für die Auswahl einer Certificate-Lifecycle-Management-Lösung
Eine geeignete Plattform sollte mehr können, als vor einem bevorstehenden Ablauf zu warnen. Wichtig ist, welchen Anteil des gesamten Lifecycle sie wirklich steuern und automatisieren kann.
Bei der Bewertung helfen folgende Fragen:
- Kann die Lösung den vorhandenen Zertifikatsbestand zentral erfassen und verwalten?
- Welche Zertifizierungsstellen und bestehenden PKI-Systeme lassen sich integrieren?
- Welche Lifecycle-Schritte können automatisiert werden?
- Unterstützt die Plattform standardisierte Schnittstellen und Protokolle wie ACME?
- Können unterschiedliche Richtlinien, Zertifikatsprofile und Sicherheitsanforderungen abgebildet werden?
- Welche Monitoring- und Reporting-Funktionen stehen zur Verfügung?
- Kann die Lösung auch in großen IT-Landschaften betrieben werden?
Gerade bei verteilten Umgebungen sollte geprüft werden, wie Zielsysteme angebunden werden und welche manuellen Schritte nach der automatisierten Ausstellung übrig bleiben. Eine automatisierte CA-Anfrage allein bildet noch keinen automatisierten Zertifikatslebenszyklus.
Certificate Lifecycle Management mit SITS und keyon true-Xtender
SITS unterstützt Unternehmen dabei, bestehende PKI- und Zertifikatsprozesse zu analysieren und gezielt weiterzuentwickeln. Mit keyon true-Xtender können vorhandene PKI-Umgebungen um Funktionen für automatisierte Ausstellung und Erneuerung, regelbasierten Widerruf sowie zentrale Monitoring- und Reporting-Funktionen ergänzt werden. Im Mittelpunkt steht dabei die Weiterentwicklung der bestehenden Umgebung: Vorhandene PKI-Strukturen können weiter genutzt und Zertifikatsprozesse schrittweise stärker automatisiert werden.
Fazit: Kürzere TLS-Zertifikatslaufzeiten brauchen neue Renewal-Prozesse
Die neuen Laufzeiten verändern nicht grundsätzlich, was Unternehmen mit öffentlich vertrauenswürdigen TLS-Zertifikaten tun müssen. Sie verändern vor allem, wie oft diese Schritte durchgeführt werden müssen.
Aus einer gelegentlichen Administrationsaufgabe wird damit ein kontinuierlicher Betriebsprozess. Tabellen, Kalender und manuelle Tickets geraten bei steigender Renewal-Frequenz an praktische Grenzen und erhöhen das Risiko, einzelne Zertifikate zu übersehen oder fehlerhaft auszutauschen.
Ein zentrales Certificate Lifecycle Management verbindet deshalb Inventarisierung, Verantwortlichkeiten, Richtlinien, automatisierte Erneuerungen, technische Validierung und Monitoring. Unternehmen müssen nicht jeden Prozess auf einmal automatisieren. Sie sollten jedoch frühzeitig erfassen, wo öffentlich vertrauenswürdige TLS-Zertifikate eingesetzt werden und welche Systeme zuerst in einen kontrollierten Zyklus überführt werden müssen.
Bereit für kürzere Zertifikatslaufzeiten?
Bereiten Sie Ihre PKI rechtzeitig auf die neuen Anforderungen vor. Unsere Experten unterstützen Sie dabei, bestehende Zertifikatsprozesse zu analysieren und Certificate Renewal Schritt für Schritt zu automatisieren.
Certificate Lifecycle Management (CLM) bezeichnet den Prozess der Verwaltung digitaler Zertifikate über ihren gesamten Lebenszyklus hinweg, einschließlich Erfassung, Ausstellung, Bereitstellung, Verlängerung, Überwachung und Widerruf.
Ein abgelaufenes TLS-Zertifikat kann zu Browserwarnungen, fehlgeschlagenen Verbindungen, API-Störungen und Anwendungsausfällen führen. Automatisierte Verlängerungsprozesse tragen dazu bei, dieses Risiko zu verringern.
Die jeweilige Grenze richtet sich nach dem Ausstellungsdatum. Zertifikate, die vor Inkrafttreten einer neuen Stufe regelkonform ausgestellt wurden, werden durch die nächste Stufe nicht automatisch ungültig. Für die nachfolgende Ausstellung oder Erneuerung gilt jedoch die dann aktuelle maximale Laufzeit.
Die erste Verkürzung auf maximal 200 Tage gilt bereits seit dem 15. März 2026. Die nächste Stufe auf maximal 100 Tage tritt am 15. März 2027 in Kraft. Unternehmen sollten daher bestehende Renewal-Prozesse jetzt überprüfen und insbesondere bei öffentlich vertrauenswürdigen TLS-Zertifikaten klären, welche Schritte noch manuell erfolgen.
Der wichtigste erste Schritt ist eine Übersicht über Zertifikate, Einsatzorte, Ablaufdaten und Verantwortlichkeiten. Ohne diese Transparenz lässt sich nicht zuverlässig entscheiden, welche Zertifikate zuerst automatisiert werden müssen.
Gemäß der Roadmap des CA/Browser-Forums wird die Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate bis März 2029 auf 47 Tage verkürzt. Das bedeutet, dass Unternehmen ihre Zertifikate möglicherweise etwa alle sechs bis sieben Wochen erneuern müssen
