Warum die Änderungen bei Let's Encrypt vom 13. Mai wichtig sind

Am 13. Mai 2026 nahm Let's Encrypt drei Produktionsänderungen gleichzeitig vor: Das Opt-in-Profil tlsserver begann mit der Ausstellung von 45-Tage-Zertifikaten, das Profil tlsclient wurde vor dem Stichtag am 8. Juli 2026 abgeschaltet, und das Standardprofil wechselte fünf Tage nach einem zweieinhalbstündigen Ausstellungsstopp zu Generation-Y-Zwischenzertifikaten.

Einzeln betrachtet ist jede Änderung beherrschbar. Zusammengenommen, insbesondere im Kontext des fünf Tage zuvor stattgefundenen Ausstellungsvorfalls, senden sie jedoch eine klare Botschaft an alle Zertifikatsverantwortlichen: Die Zeiten, in denen die Zertifikatsverwaltung als gelegentliche Papierarbeit behandelt wurde, sind vorbei. Der Zertifikatsbetrieb entwickelt sich zu einer Infrastrukturkomponente, und Organisationen, die diesen Wandel noch nicht vollzogen haben, werden jede zukünftige Änderung als hektisches Durcheinander empfinden.

Dieser Blogbeitrag erläutert, was sich geändert hat, warum ein kurzer Ausfall einige Tage zuvor von größerer Bedeutung war, als seine kurze Dauer vermuten lässt, und was uns diese Ereignisse über die zukünftige Entwicklung des Zertifikatsmanagements in der gesamten Branche verraten.

Wichtige Erkenntnisse

• Am 13. Mai 2026 stellte Let's Encrypt das tlsserver-Profil auf 45-Tage-Zertifikate um, das tlsclient-Profil wurde bis zum 8. Juli 2026 abgeschaltet, und das Standardprofil wechselte zu Generation-Y-Zwischenzertifikaten.
• Diese Änderungen folgten auf einen Emissionsstopp vom 8. Mai 2026, der durch fehlende Felder für die erweiterte Schlüsselverwendung auf neu ausgestellten, kreuzsignierten Zwischenzertifikaten verursacht wurde und innerhalb von etwa zweieinhalb Stunden mithilfe von ACME Renewal Information (ARI) behoben werden konnte.
• Der Wahlvorschlag SC-081v3 des CA/Browser Forums sieht eine schrittweise Verlängerung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate von 200 Tagen (März 2026) über 100 Tage (März 2027) auf 47 Tage (März 2029) vor, wodurch das 45-Tage-Profil von Let's Encrypt zu einer Vorschau und nicht zu einem Ausreißer wird.
• Laut der Trust Pulse Survey von DigiCert gaben 45 % der Unternehmen an, im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten erlebt zu haben, und 37.5 % konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen.
• Die Teams für PKI, Sicherheit, Plattform und Compliance sind jeweils für einen bestimmten Aufgabenbereich vor der Abschaltung von tlsclient am 8. Juli 2026 zuständig; die untenstehende Verantwortlichkeits-/Aufgabenmatrix und die Zeitleiste zeigen genau, was und wer dafür verantwortlich ist.

Direkt zu: Zusammenfassung | Checkliste zur Einsatzbereitschaft | Der Vorfall vom 8. Mai | Die drei Änderungen | Zeitleiste | Verantwortlichkeits-/Maßnahmenmatrix | Nächste Schritte | FAQ

Zusammenfassung für die Teams PKI, Sicherheit, Plattform und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die in diesem Artikel unterstützte Entscheidung und die entsprechende Kurzanleitung.

• PKI-Teams: Bestätigen Sie, dass die festgelegten Root- und Zwischenlisten die aktuelle Generation-Y-Kette enthalten, und testen Sie die Erneuerungsautomatisierung anhand des optionalen 45-Tage-TLS-Server-Profils, bevor eine kürzere Gültigkeitsdauer branchenweit obligatorisch wird.
• Sicherheitsteams: Ermitteln Sie vor dem Stichtag am 8. Juli 2026 alle Zertifikate, die die erweiterte Schlüsselverwendung des TLS-Clients (Client-Authentifizierung) nutzen, und planen Sie die Migration zu einer privaten PKI oder einer kommerziellen Zertifizierungsstelle.
• Plattform-/DevSecOps-Teams: Ersetzen Sie die Auslöser für die Erneuerung nach einer festen Tagesanzahl durch eine ARI-gesteuerte oder auf einem Bruchteil der Lebensdauer basierende Logik, damit ein 45-Tage-Zertifikat nicht ohne Erneuerung abläuft.
• Compliance-Teams: Bestätigen Sie, dass die Überprüfung der Zertifikatskette und die Überwachung des Ablaufs kontinuierlich erfolgen und nicht nur als einmaliger Einrichtungsschritt, und dokumentieren Sie, wie Änderungen an Root- und Profilzertifikaten von der Richtlinie aufgenommen werden.

Kurzcheckliste zur Einsatzbereitschaft

Nutzen Sie diese Checkliste, um zu beurteilen, wie gut Ihre Zertifikatsprozesse auf die Ereignisse vom 8. Mai und 13. Mai 2026 sowie auf die noch bevorstehenden kürzeren Gültigkeitszeiträume vorbereitet sind.

• Prüfen Sie, ob Ihr ACME-Client ACME Renewal Information (ARI) für CA-gesteuerte Verlängerungszeitpunkte unterstützt.
• Die Auslöser für eine verifizierte Verlängerung basieren auf einem Bruchteil der Zertifikatslaufzeit, nicht auf einer festen Tagesanzahl, die von einem 90-Tage-Zertifikat ausgeht.
• Führen Sie eine Zertifikatssuche durch, die nach erweiterter Schlüsselverwendung filtern kann, um jedes Zertifikat zu finden, das die tlsclient-Authentifizierung verwendet.
• Für alle Client-Authentifizierungszertifikate, die vor dem 8. Juli 2026 gefunden wurden, wurde ein Migrationspfad (private PKI oder kommerzielle CA) ermittelt.
• Zu den bestätigten, fest verankerten Wurzeln oder Zwischenknoten in Ihrer eigenen Infrastruktur gehört die aktuelle Generation Y-Chain.
• Die Automatisierung der Zertifikatserneuerung wurde nicht nur mit einer 90-tägigen, sondern auch mit einer 45-tägigen Zertifikatslaufzeit getestet.

Eine kurze Zusammenfassung: Der Vorfall vom 8. Mai

Fünf Tage vor den geplanten Änderungen setzte Let's Encrypt die Ausstellung aller Zertifikate aus. Die Unterbrechung dauerte etwa zweieinhalb Stunden, bevor die Ausstellung wieder aufgenommen wurde. Die Ursache war ein Konfigurationsproblem in neu ausgestellten, kreuzsignierten Zwischenzertifikaten: Ihnen fehlten die erforderlichen Felder für die erweiterte Schlüsselverwendung. Die Lösung bestand darin, die betroffenen Zwischenzertifikate zu widerrufen und mit den korrekten Feldern neu auszustellen. Wichtig ist, dass keine Endbenutzerzertifikate – also die auf den Servern eingesetzten Zertifikate – widerrufen wurden, da diese weiterhin den Anforderungen entsprachen.

Um die dadurch entstandene Welle an Erneuerungen reibungslos zu bewältigen, nutzte Let's Encrypt ACME Renewal Information (ARI), eine Protokollerweiterung, die es einer Zertifizierungsstelle ermöglicht, ACME -Clients über den Zeitpunkt der Erneuerung zu informieren. Anstatt dass alle betroffenen Clients gleichzeitig erneuerten und das System überlasteten, verteilte ARI die Erneuerungen gestaffelt über ein kontrolliertes Zeitfenster. Bei Clients, die ARI unterstützen, wurde die korrigierte Zertifizierungskette beim nächsten geplanten Lauf automatisch übernommen – ein manuelles Eingreifen war nicht erforderlich.

Der Vorfall wurde zwar zufriedenstellend behoben, doch er hat eine wichtige Lektion gelehrigt: Die Überprüfung der Zertifikatskette ist keine einmalige Angelegenheit mehr. Stammzertifikate ändern sich, Kreuzsignaturen werden repariert und Vertrauensspeicher werden automatisch aktualisiert. Die Überprüfung der korrekten Zertifikatskette muss daher ein kontinuierlicher, protokollierter Bestandteil Ihres Erneuerungsprozesses sein und darf nicht länger eine verstaubte Prüfung in einem veralteten Bereitstellungshandbuch sein.

Die drei Veränderungen am 13. Mai

1. Das tlsserver-Profil wurde auf 45-Tage-Zertifikate umgestellt.

Das optionale TLS-Server-Profil stellt Zertifikate mit einer Gültigkeit von nur 45 Tagen aus. Dieses Profil richtet sich an Early Adopters, die ihre Automatisierung anhand eines kurzen Erneuerungszyklus testen möchten, bevor dieser unumgänglich wird. Es markiert den Beginn einer branchenweiten Entwicklung hin zu 47-Tage-TLS-Zertifikaten und eignet sich daher hervorragend als Testumgebung. Wenn Ihre Automatisierung heute mit einem 45-Tage-Zertifikat umgehen kann , wird sie auch die zukünftigen Anforderungen erfüllen.

Der operative Haken ist subtil, aber gravierend. Viele ACME-Clients sind so konfiguriert, dass sie eine feste Anzahl von Tagen vor Ablauf erneuern, oft 30 Tage. Bei einem 90-Tage-Zertifikat ist die Erneuerung 30 Tage vorher unproblematisch, da sie etwa zwei Drittel der Zertifikatslaufzeit auslöst. Diese 90-Tage-Regelung liegt jedoch bereits hinter dem Zeitplan des CA/Browser Forums zurück, der die Gültigkeit öffentlicher TLS-Zertifikate ab März 2026 auf 200 Tage begrenzt und danach kontinuierlich verkürzt. Daher sollte diese Regelung als veraltet und nicht als aktuell betrachtet werden. Bei einem 45-Tage-Zertifikat würde dieselbe feste Einstellung versuchen, die Erneuerung bereits nach 15 Tagen zu erzwingen. Die Automatisierung kann dies als Fehler interpretieren und die Erneuerung überspringen, manchmal sogar unbemerkt. Das Zertifikat verfällt dann ohne Erneuerung. Der korrekte Ansatz ist eine Erneuerungslogik, die auf einem Bruchteil der Zertifikatslaufzeit basiert, oder noch besser eine ARI-gesteuerte, sodass die Zertifizierungsstelle selbst das richtige Erneuerungsfenster signalisiert.

2. Das tlsclient-Profil wurde heruntergefahren.

Das tlsclient-Profil, das zur Ausstellung von Zertifikaten für die TLS-Clientauthentifizierung verwendet wurde, wurde am 13. Mai eingefroren. Bestehende Konten, die es bereits verwendet hatten, konnten vorübergehend weiter genutzt werden, aber neuen Konten wurde kein Zugriff mehr gewährt. Als endgültiger Stichtag wurde der 8. Juli 2026 festgelegt, nach dem das Profil vollständig verschwindet.

Diese Änderung ist keine Besonderheit von Let's Encrypt. Sie basiert auf einer umfassenderen Anforderung der großen Browser- und Betriebssystemhersteller, die vorschreibt, dass die TLS- Client- und die TLS-Serverauthentifizierung in separate Public-Key-Infrastrukturen aufgeteilt werden müssen. Die praktische Konsequenz ist erheblich: Systeme, die zur Authentifizierung eines Clients gegenüber einem Server ein Let's-Encrypt-Zertifikat nutzten – wie beispielsweise interne Mutual-TLS-Systeme, bestimmte XMPP-Dienste oder Anwendungen mit Clientauthentifizierung – funktionieren nicht mehr, sobald das entsprechende Profil entfernt wird.

Die eigentliche Herausforderung liegt selten in der Migration selbst, sondern darin, den Speicherort dieser Zertifikate zu ermitteln. Client-Authentifizierungszertifikate werden häufig von einzelnen Anwendungsteams für spezifische Integrationen bereitgestellt und sind daher in zentralen PKI- Inventaren nicht verfügbar. Um sie zu finden, ist eine Zertifikatserkennung erforderlich , die nach erweiterter Schlüsselverwendung filtert und Zertifikate anhand ihrer tatsächlichen Konfiguration anstatt anhand des Hostnamens in Cloud-, On-Premises- und Containerumgebungen anzeigt. Sobald die Zertifikate gefunden sind, werden interne Anwendungsfälle typischerweise auf eine private PKI migriert, während externe Anwendungsfälle, die tatsächlich eine Client-Authentifizierung benötigen, zu einer kommerziellen Zertifizierungsstelle wechseln. Unser Leitfaden zum Aufbau einer privaten PKI für mTLS beschreibt diesen Migrationspfad detailliert.

3. Das klassische Profil wurde auf die Generation Y (mittlere Generation) übertragen.

Das standardmäßige klassische ACME-Profil, das von den meisten Let's Encrypt-Abonnenten ohne explizite Konfiguration verwendet wird, verwendet nun die neuen Zwischenzertifikate der Generation Y. Für die meisten automatisierten Systeme verläuft dieser Übergang transparent, doch er verdeutlicht die Lehre aus dem Vorfall vom 8. Mai: Vertrauensketten verändern sich im Hintergrund, und die einzige sichere Annahme ist, dass dies auch weiterhin so sein wird. Organisationen, die bestimmte Stamm- oder Zwischenzertifikate in ihrer eigenen Infrastruktur festgelegt haben, müssen sicherstellen, dass ihre signierten Zwischenzertifikate aktuell sind, um schwerwiegende Validierungsfehler in der Kette zu vermeiden.

Zeitleiste: Gültigkeitsdaten, Anforderungen und Quellen

Nutzen Sie diese Tabelle als Referenz, um genau zu erfahren, was sich geändert hat, wann die Änderung in Kraft getreten ist, wen sie betrifft und was dagegen zu tun ist, jeweils unter Angabe der ursprünglichen politischen Quelle.

Datum des Inkrafttretens	Anforderung / Änderung	Wer ist betroffen?	Erforderliche Maßnahmen	Quelle
May 8, 2026	Let's Encrypt setzte die Ausstellung für etwa 2.5 Stunden aus, nachdem in neu ausgestellten, kreuzsignierten Zwischenzertifikaten fehlende Felder für die erweiterte Schlüsselverwendung festgestellt wurden.	Alle Let's Encrypt-Abonnenten, die auf die betroffenen Zwischenspeicher angewiesen sind	Bestätigen, dass ARI-basierte Clients die korrigierte Kette automatisch übernommen haben; überprüfen, ob die Kettenvalidierung kontinuierlich läuft.	Offenlegung des Let's Encrypt-Vorfalls
May 13, 2026	Das Opt-in-TLS-Server-Profil beginnt mit der Ausstellung von 45-Tage-Zertifikaten.	Pioniere testen die Automatisierung auf Herz und Nieren, bevor der branchenweite Wandel bevorsteht	Ersetzen Sie feste Verlängerungsauslöser mit einer Laufzeit von 30 Tagen durch eine auf der Lebensdauer basierende oder ARI-gesteuerte Logik.	Let's Encrypt-Profildokumentation
13. Mai 2026 (eingefroren); 8. Juli 2026 (abgeschaltet)	Das tlsclient-Profil wurde für neue Konten eingefroren und anschließend für alle Konten vollständig abgeschaltet.	Systeme, die Let's Encrypt-Zertifikate für interne mTLS-, XMPP- oder clientseitig authentifizierte Anwendungen verwenden	Entdecken Sie jetzt Client-Authentifizierungs-EKU-Zertifikate und migrieren Sie vor dem 8. Juli 2026 zu einer privaten PKI oder einer kommerziellen Zertifizierungsstelle.	Trennungsanforderung für Client- und Serverauthentifizierung im Root-Programm
May 13, 2026	Standardmäßig wechselt das klassische Profil zu den Zwischenstufen der Generation Y.	Die Mehrheit der Let's Encrypt-Abonnenten, insbesondere diejenigen, die bestimmte Stamm- oder Zwischenverschlüsselungsstellen festlegen	Überprüfen Sie, ob die festgelegten Stamm-/Zwischenlisten die aktuelle Generation-Y-Kette enthalten.	Let's Encrypt Generation Y Zwischenankündigung
15. März 2026 → 15. März 2027 → 15. März 2029	Die maximale Gültigkeitsdauer des öffentlichen TLS-Zertifikats wurde schrittweise von 200 Tagen auf 100 Tage und schließlich auf 47 Tage reduziert.	Alle Inhaber öffentlicher TLS-Zertifikate, weit über die Abonnentenbasis von Let's Encrypt hinaus.	Verabschieden Sie sich von den veralteten Verlängerungszyklen von über 90 Tagen und setzen Sie auf ein kontinuierliches, automatisiertes Lebenszyklusmanagement.	CA/Browser Forum Abstimmung SC-081v3; Sectigo, Analyse vom 14. April 2025

Diese Gültigkeitsdaten basieren auf Daten darüber, was passiert, wenn diese Disziplin missachtet wird. Laut der DigiCert Trust Pulse Survey vom 2. Juli 2025 verzeichneten 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten, und 37.5 % konnten einen Ausfall eindeutig auf ein abgelaufenes Zertifikat zurückführen . Dieselben Faktoren treiben die oben genannten Profiländerungen voran: Der CA/Browser Forum-Abstimmungsantrag SC-081v3, bestätigt durch die Analyse von Sectigo vom 14. April 2025 , reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate schrittweise auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029. Damit ist das optionale 45-Tage-TLS-Server-Profil von Let's Encrypt ein Vorbote dessen, wohin sich alle öffentlichen Zertifizierungsstellen entwickeln werden, und keine isolierte politische Entscheidung.

Das große Ganze: Ein branchenweiter Wandel, keine Veranstaltung für einzelne Anbieter.

Es wäre ein Fehler, diese Änderungen als reine Anpassungen bei Let's Encrypt zu interpretieren. Sie geben vielmehr einen Ausblick auf die zukünftige Entwicklung des gesamten Ökosystems öffentlicher Zertifikate. Das CA/Browser Forum hat die Gültigkeitsdauer öffentlicher TLS-Zertifikate bis 2029 auf 47 Tage verkürzt, mit Zwischenschritten, in denen weitere Reduzierungen vorgesehen sind. Browser-Root-Programme verschärfen die Anforderungen an die Verwendung von Zertifikaten. Der Widerruf von Zertifikaten erfolgt nicht mehr über ältere Mechanismen, sondern über kürzere Gültigkeitsdauern, wodurch ein Widerruf nahezu überflüssig wird, da ein Zertifikat mit einer Gültigkeitsdauer von nur wenigen Tagen oder Wochen praktisch von selbst abläuft.

Jede Zertifizierungsstelle durchläuft ihre eigenen Prozesse der Root-Migration, Profiländerung und Lebensdauerverkürzung. Der nächste Prozess ist immer schon irgendwo im Gange. Vor diesem Hintergrund sind die Änderungen vom 13. Mai weit über die Nutzer von Let's Encrypt hinaus von Bedeutung.

Die grundlegende Frage, die diese Ereignisse aufwerfen, betrifft die Struktur einer Organisation, die solche Entwicklungen bewältigen kann. Teams, die Zertifikatsverwaltung als Infrastruktur betrachten, behandeln jede Änderung wie ein Konfigurationsupdate, da ihre Erneuerungen durch Zertifikatsautomatisierung vollständig automatisiert sind , ihr Bestand in Echtzeit geführt wird und mit allen genutzten Zertifizierungsstellen kompatibel ist und ihre Krypto-Agilität eine integrierte Eigenschaft ihrer Plattform und kein separates Projekt ist. Teams, die Zertifikate hingegen als Papierkram behandeln, arbeiten mit Tabellenkalkulationen, Ticketwarteschlangen und veralteten Handbüchern. Für sie wird jede Änderung der Zertifizierungsstelle zu einem mehrwöchigen Wettlauf gegen die Zeit, den auch Überstunden nicht bewältigen können.

Die immer kürzer werdenden Gültigkeitsdauern verschärfen diese Lücke nur noch. Ein Erneuerungsprozess, der auf 90-Tage-Zertifikate ausgelegt ist, hält einem 45-Tage-Zyklus nicht stand, und die Zeit für eine Überarbeitung ist kürzer als die Frist selbst. Unternehmen, die jetzt in Automatisierung investieren, lösen nicht nur das Problem von heute. Sie schaffen sich die Voraussetzungen, um auch in Zukunft mit kürzeren Gültigkeitsdauern und der anschließenden Migration nach der Quantentechnologie bestehen zu können.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI-Team	Besitzt die Wurzel- und Zwischenwährungskette	Prüfen Sie, ob die festgelegten Wurzeln/Zwischenprodukte die Generation-Y-Kette und das Modell-Erneuerungsvolumen im Vergleich zum 45-Tage-Profil enthalten.
Sicherheits Team	Verantwortlich für die Ermittlung und Migration von Client-Authentifizierungszertifikaten	Führen Sie die EKU-basierte Erkennung in Cloud-, On-Premises- und Containerumgebungen vor dem 8. Juli 2026 durch.
Plattform-/DevSecOps-Team	Besitzt eine automatisierte, lebensdauerorientierte Verlängerungslogik	Ersetzen Sie die Auslöser für die Erneuerung anhand einer festen Tagesanzahl durch ARI-gesteuerte oder auf Lebensdaueranteilen basierende Automatisierung.
Compliance-Team	Besitzt Nachweise zur lückenlosen Lieferkette und zum Ablaufdatum.	Die Überprüfung der Bestätigungskette und die Überwachung des Ablaufs werden kontinuierlich protokolliert und nicht nur einmalig bei der Bereitstellung geprüft.

Was macht man als nächstes

• PKI-Teams: Bitte bestätigen Sie, dass alle fixierten Stamm- und Zwischenlisten für die Generation Y-Kette in diesem Quartal aktualisiert wurden.
• Sicherheitsteams: Die vollständige Ermittlung der tlsclient/client-authentication-Zertifikate und die sofortige Planung der Migration sollten rechtzeitig vor der Abschaltung am 8. Juli 2026 erfolgen.
• Plattformteams: Pilot-Lebensdaueranteil- oder ARI-gesteuerte Erneuerungslogik gegen das Opt-in 45-Tage-TLS-Server-Profil, bevor es zum Branchenstandard wird.
• Compliance-Teams: Es muss dokumentiert werden, dass die Überprüfung der Kontrollkette und die Überwachung des Verfallsdatums kontinuierlich erfolgen, sodass der nächste CA-Vorfall ein Beweis für eine funktionierende Kontrolle und nicht für eine Lücke ist.

Wie Verschlüsselungsberatung helfen kann

Die Lehre aus dem 13. Mai ist, dass Zertifikatsverwaltungssysteme als ausfallsichere Infrastruktur funktionieren müssen. Encryption Consulting bietet die Produkte und das Know-how, um genau das zu realisieren.

CertSecure Manager ist unsere Lösung für das Zertifikatslebenszyklusmanagement, die speziell für die von diesen Veränderungen beschriebenen Anforderungen entwickelt wurde. Sie ermöglicht die kontinuierliche, CA-unabhängige Erkennung von Zertifikaten in Cloud-, On-Premises- und Kubernetes-Umgebungen. So finden Sie jedes Ihrer Zertifikate, einschließlich der Client-Authentifizierungszertifikate, die Anwendungsteams außerhalb der zentralen PKI bereitgestellt haben und die in keiner Tabellenkalkulation erfasst werden.

Die durchgängige Automatisierung von Ausstellung, Verlängerung und Widerruf ist speziell für kurzlebige Zertifikate und häufige Verlängerungen ausgelegt und vermeidet die Fallstricke fester Intervalle, die zu unbemerkten Ausfällen führen können. Dank zentralisierter Richtliniendurchsetzung und Echtzeit-Inventarisierung wird eine Root-Migration oder Profiländerung zu einer einfachen Konfigurationsaktualisierung und nicht zu einem Notfalleinsatz. Durch die kontinuierliche statt einmalige Überprüfung der Zertifikatskette und die Überwachung des Ablaufdatums verhindert CertSecure Manager Ereignisse wie die vom 8. und 13. Mai.

Um die Transparenz Ihrer gesamten kryptografischen Umgebung zu erweitern, erfasst und inventarisiert CBOM Secure die Algorithmen, Schlüssel und Protokolle in Ihrer Umgebung. So erhalten Sie die kryptografische Stückliste, die sowohl die Einhaltung von Vorschriften als auch die Vorbereitung auf den Übergang zur Post-Quanten-Verschlüsselung mit kürzeren Zertifikatslebensdauern unterstützt. Unser Leitfaden „CBOM: Von der Bestandsaufnahme zur Analyse “ beschreibt, wie Sie diese Bestandsaufnahme in ein kontinuierliches Programm zur Steigerung der Krypto-Agilität umwandeln. Unser PQC Center of Excellence und unser 9-phasiger PQC-Readiness -Plan helfen Ihnen bei der Planung des Übergangs zur Post-Quanten-Verschlüsselung nach dieser Ära immer kürzerer Zertifikatslebensdauern.

Im Beratungsbereich unterstützt unser PKI-Services -Team Unternehmen bei der Konzeption und Modernisierung ihrer PKI-Umgebungen (Unternehmen und Microsoft), die zunehmend Anwendungsfälle übernehmen müssen, von denen sich öffentliche Zertifizierungsstellen zurückziehen – beispielsweise Client-Authentifizierungszertifikate, die von diesen Änderungen betroffen sind. Unsere Beratungsdienste im Bereich Verschlüsselung helfen Ihnen beim Aufbau einer robusten, auf Automatisierung ausgerichteten Zertifikatsstrategie, und unsere Compliance-Beratungsdienste sorgen dafür, dass diese Strategie mit den sich ständig weiterentwickelnden regulatorischen und browserprogrammspezifischen Anforderungen übereinstimmt.

Ob Sie nun vor dem Stichtag im Juli noch schnell Ihre Client-Authentifizierungszertifikate inventarisieren oder eine langfristige Automatisierung aufbauen möchten, die die nächsten Änderungen zum Kinderspiel macht – Encryption Consulting unterstützt Sie dabei. Kontaktieren Sie uns, um Ihre Zertifikatsprozesse zu analysieren und sich optimal auf die Zukunft vorzubereiten.

Weiterführende Lektüre von Encryption Consulting

• Stärkere Sicherheit durch TLS-Zertifikate mit 47-tägiger Gültigkeit bis 2029 deckt den gesamten Gültigkeitsprüfungsprozess des CA/Browser-Forums ab, den Let's Encrypt mit seinem 45-Tage-Profil testet.
• Erstellen Sie eine private PKI für mTLS, bevor öffentliche Zertifikate die Clientauthentifizierung verwerfen. Deckt genau den Migrationspfad ab, den Teams vor der Abschaltung des tlsclient-Profils am 8. Juli 2026 benötigen.
• Änderungen bei Client-Authentifizierungszertifikaten: Chromes mTLS-Umstellung 2026 deckt die Browser-Root-Programmanforderung ab, die das Herunterfahren des tlsclient-Profils auslöst.
• Zertifikatstransparenzüberwachung im Zeitalter der statischen Stromwandler umfasst die Überwachungsdisziplin, die mit der kontinuierlichen Kettenverifizierung einhergeht.

Fazit

Die Änderungen bei Let's Encrypt vom 13. Mai und der ihnen vorausgehende kurze Ausfall sind einzeln betrachtet geringfügig. Ihre eigentliche Bedeutung liegt in ihrer Signalwirkung. Die Gültigkeitsdauer von Zertifikaten sinkt branchenweit, Vertrauensketten ändern sich häufiger und die Regeln für deren Verwendung werden verschärft. Diese Entwicklung wird sich ungebremst fortsetzen.

Die Organisationen, die diese Veränderungen reibungslos bewältigen, sind nicht diejenigen, die bei jeder Änderung durch eine Zertifizierungsstelle am meisten Aufwand betreiben. Sie sind diejenigen, die aufgehört haben, Zertifikate als Papierkram zu behandeln und ihre Zertifikatsverwaltung auf eine automatisierte, transparente und CA-unabhängige Infrastruktur aufgebaut haben. Diese Grundlage ermöglicht einen 45-tägigen Zyklus, die Abschaltung von Profilen und die Migration der Stammzertifizierungsstelle als Routinevorgänge. Sie ist auch die Grundlage, die eine Organisation durch den noch bevorstehenden Übergang nach der Quantenzertifizierung tragen wird.

Die nächste Änderung ist bereits im Anmarsch, sei es von Let's Encrypt oder aus einem anderen Bereich des Ökosystems. Die einzige wirkliche Frage ist, ob Ihre Zertifikatsverwaltung darauf vorbereitet ist, sie als Konfigurationsaktualisierung zu behandeln oder ob sie als weiterer Notfall eingestuft wird.

Da dieser Beitrag die Einführung der Richtlinien eines bestimmten Anbieters verfolgt, wird er vierteljährlich überprüft und sofort aktualisiert, sobald das CA/Browser Forum, ein Browser-Root-Programm oder Let's Encrypt selbst eine weitere Änderung ankündigt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Artikel „Warum die Änderungen von Let's Encrypt vom 13. Mai wichtig sind“?

Die Profiländerungen von Let's Encrypt vom 13. Mai 2026, die auf den Vorfall vom 8. Mai folgten, zeigen, dass sich das Zertifikatslebenszyklusmanagement von gelegentlicher Wartung hin zu einer kontinuierlichen, automatisierten Infrastruktur entwickelt. Organisationen, die noch immer auf Tabellenkalkulationen und regelmäßige Erneuerungen setzen, werden jede zukünftige Änderung der Zertifizierungsstelle als Notfall empfinden, während Organisationen mit einer lebenszyklusorientierten, ARI-gesteuerten Automatisierung dieselbe Änderung als Routinekonfiguration bewältigen.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig?

Die Trust Pulse-Umfrage von DigiCert ergab, dass 45 % der Unternehmen im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten verzeichneten und 37.5 % einen Ausfall eindeutig auf ein abgelaufenes Zertifikat zurückführen konnten. Der Zeitplan des CA/Browser Forums sieht eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage bis März 2026, 100 Tage bis März 2027 und 47 Tage bis März 2029 vor. Das optionale 45-Tage-TLS-Server-Profil von Let's Encrypt ist der branchenweit führende Beweis dafür, dass diese Regelung schneller umgesetzt wird, als viele Erneuerungsprozesse vorgesehen sind.

Welche Teams sind für die Umsetzung dieser Richtlinien verantwortlich?

PKI-Teams sind für die Root- und Zwischenzertifikatskette zuständig; Sicherheitsteams für die Ermittlung und Migration von Client-Authentifizierungszertifikaten; Plattform- und DevSecOps-Teams für die automatisierte, lebensdauerbewusste Erneuerungslogik; und Compliance-Teams für die kontinuierliche Überwachung der Zertifikatskette und des Ablaufdatums. Die obige Verantwortlichkeits-/Aufgabenmatrix zeigt die Aufschlüsselung nach Team.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Handhabung führt dazu, dass die Logik zur Erneuerung von Zertifikaten mit fester Gültigkeitsdauer bei kurzlebigen Zertifikaten stillschweigend fehlschlägt, da ein 30-Tage-Trigger bei einem 45-Tage-Zertifikat bereits nach 15 Tagen versucht, es zu erneuern, was als Fehler gewertet werden kann. Außerdem bleiben Client-Authentifizierungszertifikate außerhalb des zentralen Inventars verborgen, festgelegte Stammzertifikate verlieren stillschweigend ihre Gültigkeit, wenn eine Zertifizierungsstelle zu einer neuen Zwischenzertifizierungsstelle migriert, und die Frist für tlsclient am 8. Juli 2026 wird vollständig verpasst.

Wie reduziert Automatisierung das Risiko von Zertifikatsausfällen?

Die Automatisierung beseitigt die Annahme fester Intervalle, die bei kurzlebigen Zertifikaten nicht mehr zutrifft, indem sie die Erneuerung anhand der ACME-Erneuerungsinformationen (ARI) oder eines Bruchteils der Zertifikatslaufzeit anstatt einer fest codierten Tagesanzahl auslöst. In Kombination mit kontinuierlicher, CA-unabhängiger Erkennung und kontinuierlicher Kettenvalidierung wandelt sie eine Root-Migration, die Abschaltung eines Profils oder einen Ausstellungsvorfall in eine Konfigurationsaktualisierung anstatt in einen Ausfall um.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen?

Verfolgen Sie den Anteil der Zertifikate, deren Erneuerung auf ARI-basierter oder auf einem Bruchteil der Gültigkeitsdauer beruht, die Anzahl der vor dem 8. Juli 2026 erkannten und migrierten tlsclient/client-authentication-Zertifikate, die vor Ablauf der Gültigkeitsdauer erkannten Validierungsfehler der Zertifikatskette sowie alle Vorfälle im Zusammenhang mit Profil-, Stamm- oder Zwischenzertifikatänderungen. Berichten Sie diese Daten vierteljährlich, entsprechend dem Gültigkeitszyklus des CA/Browser Forums.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Das optionale 45-Tage-TLS-Server-Profil von Let's Encrypt dient explizit als Testfeld für die Automatisierung im Vorfeld der verbindlichen Vorgaben des CA/Browser Forums. Diese begrenzen die Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029. Automatisierungen, die das 45-Tage-Profil heute erfolgreich nutzen, werden auch die spätere, für alle anderen verbindliche 47-Tage-Gültigkeitsdauer überstehen.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Standardisieren Sie die Zertifikatserkennung und -automatisierung auf CA-unabhängige Weise, sodass Cloud-, On-Premises- und Kubernetes-Umgebungen identisch funktionieren. So durchlaufen beispielsweise Änderungen an Let's Encrypt-Profilen, Migrationen von Stammzertifikaten oder hybride PKI-Bereitstellungen alle dieselbe Richtlinie, Erneuerungslogik und denselben Prüfpfad, anstatt dass eine separate Bearbeitung pro Umgebung erforderlich ist.