Jahrelang hat eine praktische Abkürzung die Maschine-zu-Maschine-Authentifizierung weitgehend unauffällig ermöglicht: Organisationen nutzten ihre öffentlichen TLS-Zertifikate auch für die gegenseitige TLS-Authentifizierung (mTLS). Ein für einen Webserver ausgestelltes Zertifikat enthielt oft sowohl die erweiterten Schlüsselverwendungen für die Server- als auch für die Client-Authentifizierung. So konnte dasselbe Zertifikat, das einen öffentlichen Endpunkt sicherte, auch einen Client in einem mTLS-Handshake authentifizieren. Diese Abkürzung wird bald nicht mehr funktionieren, und die darauf basierenden Systeme werden nicht mit einer Warnung, sondern bei der nächsten Zertifikatserneuerung ausfallen.
Dieser Artikel erklärt die drohende ClientAuth-EKU-Klippe, ihre Ursachen, den genauen Zeitpunkt ihres Eintritts und mögliche Gegenmaßnahmen. Die meisten betroffenen Organisationen sollten die Verwendung öffentlicher Zertifikate für die Client-Authentifizierung einstellen und stattdessen eine eigens dafür entwickelte private PKI einrichten . Wir behandeln den Zeitplan, die technischen Gründe für die Divergenz zwischen öffentlichem und privatem Vertrauen, die Risiken des Nichtstuns und einen praktischen Weg zum Aufbau einer privaten PKI mit mTLS vor Ablauf der Frist.
Warum das jetzt wichtig ist
Drei Faktoren machen dies dringlich und nicht nur theoretisch. Die öffentlichen Zertifizierungsstellen, die die meisten TLS-Zertifikate ausstellen, entfernen die ClientAuth-EKU bis 2026, Chrome schließt die Umstellung auf dedizierte Serverhierarchien ab, und die Probleme treten bei der Erneuerung stillschweigend auf, anstatt an einem bestimmten angekündigten Datum. Zusammen verwandeln sie ein unauffälliges Konfigurationsdetail in eine Frist, die Zertifikat für Zertifikat näher rückt.
Chrome legt die Fristen fest
Googles Chrome-Root-Programm treibt diesen Wandel durch die Umstellung auf dedizierte, ausschließlich serverbasierte TLS-Hierarchien voran. Gemäß den Richtlinien des Chrome-Root-Programms müssen ab dem 15. Juni 2026 alle neuen Zwischenzertifizierungsstellenzertifikate (untergeordnete Zertifizierungsstellenzertifikate) ausschließlich die ServerAuth-EKU enthalten. Ab dem 15. März 2027, dem Zeitpunkt, an dem Chrome öffentlichen TLS-Zertifikaten mit ClientAuth-EKU nicht mehr vertraut, müssen alle neu ausgestellten Endzertifikate ausschließlich ServerAuth-fähig sein. Zertifikate, die vor diesen Daten ausgestellt wurden, bleiben bis zu ihrem Ablaufdatum gültig. Genau das macht diesen Übergang zu einem schleichenden Problem: Zwar tritt am Stichtag selbst keine Änderung ein, doch jede Verlängerung danach entfernt die Funktionalität, auf der mTLS basierte.
Die CAs bewegen sich noch früher
Die tatsächliche Frist liegt vor dem von Chrome angegebenen Datum, da mehrere Zertifizierungsstellen die EKU bereits deutlich vorher entfernen. Let's Encrypt entfernt die clientAuth-EKU aus Zertifikaten, die ab dem 13. Mai 2026 ausgestellt werden, Sectigo bis zum 15. Mai 2026. DigiCert hat die standardmäßige Einbindung der clientAuth-EKU am 1. Oktober 2025 eingestellt, stellt sie nun nur noch auf explizite Anfrage aus und wird sie am 1. März 2027 vollständig entfernen. Die tatsächliche Frist richtet sich daher nach der jeweiligen Zertifizierungsstelle, die Ihr Zertifikat ausstellt, und nicht nach dem von Chrome angegebenen Datum: Wenn Ihr mTLS von einem Let's Encrypt- oder Sectigo-Zertifikat abhängt, das nach Mitte Mai 2026 erneuert wird, kann es Monate vor dem Inkrafttreten der Chrome-Richtlinie nicht mehr funktionieren, da das erneuerte Zertifikat die clientAuth-EKU nicht mehr enthält.
Dies ist Teil einer bewussten Umstellung auf dedizierte Hierarchien.
Diese Änderung ist nicht willkürlich. Sie spiegelt einen branchenweiten Trend hin zu dedizierten, zweckgebundenen PKI-Hierarchien wider, der sich in den Richtlinienaktualisierungen des Chrome-Root-Programms manifestiert. Ziel ist es, mehrzweckfähige Zertifikatsvertrauensketten abzuschaffen, um die Sicherheit von Serverzertifikaten zu verbessern und deren Verwaltung zu vereinfachen. Die Ära, in der ein Zertifikat mehrere Zwecke erfüllte, geht damit bewusst zu Ende. Die Richtung wurde in den Diskussionen des CA/Browser-Forums im Oktober 2024 festgelegt und in den nachfolgenden Richtlinienversionen des Chrome-Root-Programms formalisiert. Es wird erwartet, dass sich die anderen großen Root-Programme, darunter Apple und Mozilla, anpassen werden. Daher handelt es sich hierbei um eine branchenweite Entwicklung und nicht um die Präferenz eines einzelnen Anbieters.
Funktionsweise von mTLS und der clientAuth EKU
Vor der Migrationsplanung ist es hilfreich zu verstehen, welche erweiterten Schlüsselverwendungsregeln gelten, warum Mutual TLS die spezifische Schwachstelle darstellt und warum Private PKI eine Ausnahme bildet. Die folgenden Abschnitte behandeln diese Punkte nacheinander und erläutern, warum Public Trust von vornherein das falsche Werkzeug für die interne Clientauthentifizierung war.
Was die EKU tut
Die erweiterte Schlüsselverwendung (EKU) ist eine Zertifikatserweiterung, die festlegt, wofür ein Zertifikat zur Authentifizierung verwendet werden darf. Zwei Werte sind hierbei zentral und werden durch Objektkennungen (OIDs) identifiziert: Serverauthentifizierung (id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1) und Clientauthentifizierung (id-kp-clientAuth, OID 1.3.6.1.5.5.7.3.2). Jahrelang wurden öffentliche TLS-Zertifikate mit beiden erweiterten Schlüsselverwendungen ausgestellt. Genau dies ermöglichte es, dass ein einzelnes Zertifikat in Mutual TLS sowohl als Server- als auch als Clientidentität fungieren konnte. Browser prüfen zur Herstellung einer HTTPS-Verbindung ausschließlich die serverAuth-EKU. Daher hat das Entfernen der clientAuth-EKU aus öffentlichen Serverzertifikaten keine negativen Auswirkungen auf den normalen Webbetrieb und schließt gleichzeitig eine potenzielle Missbrauchsmöglichkeit.
Warum gegenseitiges TLS das Problem ist
Bei herkömmlichem TLS legt nur der Server ein Zertifikat vor; der Client authentifiziert sich auf anderem Wege oder gar nicht. Bei Mutual TLS legen beide Enden Zertifikate vor, und das Client-Zertifikat muss die ClientAuth-EKU enthalten, um als Client-Identität akzeptiert zu werden. Organisationen, die ihre öffentlichen Serverzertifikate mit zwei EKUs für die Client-Seite von mTLS oder für die Server-zu-Server-Authentifizierung wiederverwendeten, verließen sich auf das Vorhandensein des ClientAuth-Werts. Sobald Zertifizierungsstellen diesen Wert nicht mehr angeben, enthält ein erneuertes Zertifikat nur noch ServerAuth, und der mTLS-Handshake, der eine Client-EKU erwartet, schlägt fehl. Diese Änderung betrifft Organisationen, die Serverzertifikate für die Client-Authentifizierung, beispielsweise für Mutual TLS und Server-zu-Server-Authentifizierung, verwenden. Mutual TLS ist mittlerweile das Standard-Authentifizierungsverfahren in Zero-Trust- und Service-Mesh-Architekturen. In verteilten Systemen wie Kafka, Cassandra und API-Gateways, in denen die Zertifikatsrotation automatisiert ist, kann eine einzige Erneuerung zu Authentifizierungsfehlern im gesamten Cluster führen.
Die entscheidende Ausnahme: Private PKI ist nicht betroffen.
Der wichtigste technische Aspekt für die Planung ist, dass diese Änderung nur für öffentlich vertrauenswürdige Zertifikate gilt. Die Ausnahme ist eindeutig: Diese Änderungen haben keine Auswirkungen auf die Client-Authentifizierung in privaten PKI-Systemen, da sie sich ausschließlich auf öffentlich vertrauenswürdige Zertifikate beziehen. Eine private Zertifizierungsstelle, deren Stammzertifikat nur innerhalb der eigenen Umgebung und nicht von öffentlichen Browsern als vertrauenswürdig eingestuft wird, kann Zertifikate mit der ClientAuth-EKU uneingeschränkt ausstellen. Die Übergangsphase ist ein Phänomen des öffentlichen Vertrauens, und private PKI bietet die Lösung dafür. Eine private Zertifizierungsstelle kann auf Plattformen wie Microsoft AD CS , HashiCorp Vault, AWS Private CA oder einem Managed Service betrieben werden. Client-Zertifikate können automatisch über EST, ACME oder SCEP registriert und erneuert werden . Dies ermöglicht den praktikablen Einsatz kurzlebiger Client-Zertifikate in großem Umfang.
Warum öffentliches Vertrauen ohnehin das falsche Instrument für mTLS war
Die Änderung stellt gleichzeitig eine Korrektur dar. Öffentliche Zertifikate waren nie das richtige Mittel zur internen Client-Authentifizierung, und das gesamte Zertifikatsökosystem hat dies bereits deutlich gemacht. DigiCerts eigene Richtlinien zur Reduzierung des Widerrufsrisikos plädieren dafür, verbundene Geräte und interne Dienste von öffentlichen Zertifikaten zu entkoppeln. Sie weisen darauf hin, dass es für privat vertrauenswürdige Zertifikate keine fünftägige Widerrufsfrist gibt und dass interne Anwendungen sowie die Kommunikation von Geräten in privaten Netzwerken kein öffentliches Vertrauen erfordern. Die Verwendung öffentlicher Zertifikate für mTLS setzte interne Systeme Widerrufsereignissen öffentlicher Zertifizierungsstellen und Änderungen der Root-Programmrichtlinien aus, die in keinem Zusammenhang mit dem internen Anwendungsfall standen. Private PKI beseitigt diese Kopplung vollständig. Sie bereitet die interne Authentifizierung zudem auf den breiteren Wandel hin zu kurzlebigen Zertifikaten und deren automatisierter Ausstellung vor, wodurch die manuelle Zertifikatsverwaltung nicht mehr praktikabel ist.
Risiken und Fallstricke
Die ClientAuth-Klippe birgt Risiken sowohl für diejenigen, die nichts unternehmen, als auch für diejenigen, die übereilt migrieren. Die folgende Tabelle zeigt, wo die jeweiligen Vorgehensweisen häufig zu Problemen führen.
| Risiko | Verursachen | Folge |
|---|---|---|
| Stilles Versagen bei der Erneuerung | Das öffentliche Zertifikat wird auch ohne die clientAuth EKU erneuert, nachdem die ausstellende Zertifizierungsstelle diese gelöscht hat. | mTLS-Handshakes schlagen fehl; die Authentifizierung zwischen den Diensten wird unterbrochen. |
| Versteckte Abhängigkeit | Es gibt keine Übersicht darüber, wo öffentliche Zertifikate für mTLS verwendet werden. | Zusammenbrüche in Systemen, von denen niemand wusste, dass sie auf der Abkürzung beruhten. |
| Übereilte Migration | Die Abhängigkeit wird erst bei der Erneuerung entdeckt. | Notfallmäßige Umstellung mit minimalen Tests und hohem Fehlerrisiko. |
| Kopplung des öffentlichen Vertrauens | Internes mTLS ist an die Richtlinien und Widerrufsbestimmungen der öffentlichen Zertifizierungsstelle gebunden. | Interne Ausfälle, die durch externe CA-Ereignisse verursacht wurden. |
| Nicht verwaltete private Zertifizierungsstelle | Aufbau einer privaten PKI ohne Lebenszyklusdisziplin. | Neue Schlüsselausbreitung und ein unüberwachter interner Vertrauensstamm. |
Die Gefahr besteht darin, dass die Abhängigkeit unsichtbar ist.
Die größte Herausforderung beim Wegfall der Client-Authentifizierung ist nicht die Behebung des Problems, sondern die Identifizierung der Schwachstellen. Die Wiederverwendung öffentlicher Zertifikate für mTLS ist oft undokumentiert, wurde vor Jahren von einem Team eingerichtet, das inzwischen nicht mehr im Unternehmen tätig ist, und ist in Dienst-zu-Dienst-Verbindungen eingebettet, die bis zur nächsten Zertifikatserneuerung einwandfrei funktionieren, da diese die EKU entfernt. Ohne ein Verzeichnis, das erfasst, welche Zertifikate Client-Authentifizierung beinhalten und wo sie als Client-Identitäten verwendet werden, kann ein Unternehmen erst im Nachhinein feststellen, welche Systeme bei der nächsten Erneuerung ausfallen werden. Die Identifizierung dieser Schwachstellen ist daher die erste und dringendste Aufgabe.
Finanzdienstleistungen und ähnliche Sektoren sind überproportional betroffen
Einige Branchen sind stärker von diesem Muster abhängig als andere. Die Änderung betrifft insbesondere Sektoren wie Finanzdienstleistungen und Technologiedienstleistungen, die Serverzertifikate zur Client-Authentifizierung verwenden. Unternehmen dieser Branchen sollten die damit verbundenen Ermittlungen daher dringend angehen. Für diejenigen, die tatsächlich eine öffentlich gerootete Client-Authentifizierung über Organisationsgrenzen hinweg benötigen, kann eine dedizierte X9-PKI, die den ASC-X9-Standards entspricht und außerhalb des Chrome Root Store betrieben wird, weiterhin Zertifikate mit beiden EKUs ausstellen. Im Finanzsektor wird sie genau zu diesem Zweck eingesetzt.
Best Practices für die Implementierung
Der Aufbau einer privaten PKI-mTLS-Lösung vor dem drohenden Abgrund ist ein überschaubares Projekt, wenn es mit der Analyse beginnt und mit der Automatisierung endet. Die sieben folgenden Schritte werden nacheinander ausgeführt, da man nur das abgrenzen kann, was man analysiert hat, und nur das sicher umstellen kann, was man zuvor getestet hat.
- Entdecken Sie alle mTLS-Abhängigkeiten von öffentlichen Zertifikaten: Erstellen Sie eine Bestandsaufnahme der Zertifikate, die die ClientAuth-EKU enthalten, und ermitteln Sie, wo diese als Clientidentitäten oder für die Server-zu-Server-Authentifizierung verwendet werden. Dies zeigt Ihnen genau, welche Sicherheitslücken auftreten und wann, basierend auf dem jeweiligen Erneuerungsdatum der Zertifikate. (Encryption Consulting) CBOM Secure automatisiert diese Erkennung und katalogisiert jedes Zertifikat, die darin enthaltenen EKUs und die Systeme, die davon abhängen.
- Bitte prüfen Sie die Verlängerungstermine anhand der Fristen der CA: Ordnen Sie die Erneuerung jedes betroffenen Zertifikats dem jeweiligen Abschaltdatum der ausstellenden Zertifizierungsstelle zu (13. Mai für Let's Encrypt und 15. Mai für Sectigo), wobei DigiCert clientAuth nur auf Anfrage bis zu seiner Abschaltung am 1. März 2027 ausstellt, damit Sie wissen, welche Abhängigkeiten die kürzeste Laufzeit haben.
- Einrichtung einer privaten Zertifizierungsstelle zur Clientauthentifizierung: Richten Sie eine private PKI ein, deren Stammverzeichnis nur innerhalb Ihrer Umgebung als vertrauenswürdig eingestuft wird, und stellen Sie Clientzertifikate mit der ClientAuth-EKU von dieser PKI aus. Die private PKI ist von der Änderung des öffentlichen Vertrauensstatus ausdrücklich nicht betroffen und stellt den vorgesehenen Weg für internes mTLS dar. (Encryption Consulting) PKI-as-a-Service bietet genau das: eine regulierte private Zertifizierungsstelle, die ClientAuth-Zertifikate ausstellt, ohne dass die Last des Aufbaus und Betriebs der Infrastruktur getragen werden muss.
- Saubere Trennung von Server- und Client-Vertrauensstellungen: Verwenden Sie öffentliche, ausschließlich serverauthentifizierende Zertifikate für öffentlich zugängliche Server und private Clientzertifikate für die Clientseite von mTLS. Nutzen Sie dabei das dedizierte Hierarchiemodell, anstatt dagegen anzukämpfen. Konkret bedeutet dies ein öffentliches, ausschließlich serverauthentifizierendes Zertifikat auf dem Load Balancer und ein privates, clientauthentifizierendes Zertifikat auf jedem Dienst, der sich als Client authentifiziert.
- Schutz der privaten Root-Domain und Automatisierung der Ausstellung: Verankern Sie die Signaturschlüssel der privaten Zertifizierungsstelle in einem HSM und verwenden Sie ein automatisiertes Registrierungsprotokoll wie EST oder ACME, um kurzlebige Clientzertifikate ohne manuellen Aufwand auszustellen und zu erneuern. Eine private Zertifizierungsstelle ohne Lebenszyklusautomatisierung tauscht lediglich ein Problem gegen ein anderes. HSM-as-a-Service Die private Stammzertifizierungsstelle wird in validierter Hardware verankert, und CertSecure Manager automatisiert die Ausstellung und Erneuerung, sodass kurzlebige Clientzertifikate niemals ablaufen.
- Migrieren und validieren Sie vor dem Verlängerungsdatum: Um jede mTLS-Abhängigkeit auf private Client-Zertifikate umzustellen und den End-to-End-Handshake lange vor der Erneuerung des öffentlichen Zertifikats ohne EKU zu testen, damit die Änderung geplant und nicht durch einen Ausfall ausgelöst wird.
- Die private PKI sollte wie eine Produktionsinfrastruktur verwaltet werden: Führen Sie ein Verzeichnis der ausgestellten Clientzertifikate, setzen Sie die Eigentumsrechte und die Zertifikatsrotation durch und überwachen Sie die private Stammzertifizierungsstelle, damit die neue PKI nicht zu einer neuen Quelle unkontrollierten Vertrauens wird. CertSecure Manager bietet diese Governance zentralisiert mit einem Live-Verzeichnis der ausgestellten Clientzertifikate sowie Informationen zu Eigentumsrechten, Zertifikatsrotation und Überwachung.
Wie Verschlüsselungsberatung helfen kann
Um die Herausforderungen der Client-Authentifizierung reibungslos zu meistern, sind drei Dinge entscheidend: die Identifizierung der für mTLS verwendeten öffentlichen Zertifikate, deren Ersetzung durch Zertifikate einer verwalteten privaten Zertifizierungsstelle und die Automatisierung der Zertifikatsausstellung, sodass sich die neuen Client-Zertifikate automatisch erneuern. Genau hier setzt PKI-as-a-Service von Encryption Consulting an. Es bietet eine vollständig verwaltete private Zertifizierungsstelle, die Client-Authentifizierungszertifikate unter Ihrer Kontrolle ausstellt – inklusive Profilverwaltung, Ausstellungsrichtlinien und Lebenszyklusmanagement, die für internes mTLS erforderlich sind, ohne dass Sie eine eigene Zertifizierungsstelle von Grund auf aufbauen und betreiben müssen.
Im Umfeld der privaten Zertifizierungsstelle greift das gleiche Projekt auf ein koordiniertes Angebot an Verschlüsselungsberatungsdiensten zurück, von denen jeder eine bestimmte Rolle spielt:
- PKI-as-a-Service bietet Ihnen eine vollständig verwaltete private Zertifizierungsstelle, die ClientAuth-Zertifikate unter Ihrer Kontrolle ausstellt, inklusive Profilsteuerung, Ausstellungsrichtlinien und Lebenszyklusmanagement, die Ihr internes mTLS benötigt, ohne dass Sie eine Zertifizierungsstelle von Grund auf aufbauen und betreiben müssen.
- CBOM Secure Es deckt jede versteckte mTLS-Abhängigkeit von öffentlichem Vertrauen auf, katalogisiert jedes Zertifikat, die darin enthaltenen EKUs und die Systeme, die davon abhängen, sodass Sie genau wissen, was wann kaputtgehen wird.
- CertSecure Manager automatisiert die Ausstellung und Erneuerung von Zertifikaten über öffentliche und private Zertifizierungsstellen hinweg und führt ein Live-Inventar mit Eigentumsverhältnissen, Rotation und Überwachung, sodass kurzlebige Client-Zertifikate nie ablaufen und die private PKI verwaltet bleibt.
- HSM-as-a-Service verankert die neue interne Vertrauensankerstelle in validierter Hardware und schützt so die Signaturschlüssel der privaten Zertifizierungsstelle, ohne dass neue Appliances bereitgestellt und gewartet werden müssen.
Das grundlegende Prinzip ist, dass die interne Authentifizierung auf einer von Ihnen kontrollierten, verwalteten und automatisierten Infrastruktur basieren und von den Richtlinien öffentlicher Zertifizierungsstellen entkoppelt sein sollte. So wird beispielsweise ein abrupter Wechsel der Client-Authentifizierung zu einem unbedeutenden Ereignis und nicht zu einem Ausfall. Um Ihre Sicherheitslücken zu ermitteln und vor Ihrer nächsten Zertifikatserneuerung eine private PKI mit mTLS einzurichten, wenden Sie sich an Encryption Consulting, um eine Zertifikatsanalyse und eine Bewertung Ihrer privaten PKI durchführen zu lassen.
Fazit
Die Abschaffung der clientAuth-EKU ist ein Paradebeispiel für das Ende einer praktischen Abkürzung. Die Wiederverwendung öffentlicher TLS-Zertifikate für Mutual TLS funktionierte jahrelang, doch der Branchenwandel hin zu dedizierten, zweckgebundenen Hierarchien hat dem ein Ende gesetzt. Chrome wird öffentlichen Zertifikaten mit der clientAuth-EKU nicht mehr vertrauen. Ab dem 15. Juni 2026 werden Zwischenhierarchien ausschließlich serverseitig funktionieren, Endzertifikate ab dem 15. März 2027. Da einige Zertifizierungsstellen die EKU bereits Anfang 2026 entfernen, wird mTLS, das auf dieser Abkürzung basiert, bei der nächsten Erneuerung still und leise nicht mehr funktionieren.
Die Lösung ist klar definiert: Ermitteln Sie, wo Sie für die Client-Authentifizierung auf öffentliche Zertifikate angewiesen sind. Richten Sie eine private PKI ein, die Client-Auth-Zertifikate frei ausstellen kann, da sie von der Änderung des öffentlichen Vertrauensstatus nicht betroffen ist. Trennen Sie Server- und Client-Vertrauen und automatisieren Sie die Ausstellung, sodass sich die neuen Client-Zertifikate automatisch erneuern. Beginnen Sie jetzt mit der Ermittlung, denn Ihre tatsächliche Frist wird von der Zertifizierungsstelle festgelegt, die Ihre Zertifikate erneuert, nicht von einem einzigen festgelegten Datum. Bauen Sie Ihre private PKI mTLS bewusst vor dem drohenden Umstieg auf, und die Umstellung wird zu einer geplanten Modernisierung Ihrer Infrastruktur, anstatt zu einem unerwarteten Ausfall.
