Änderungen bei Client-Authentifizierungszertifikaten: Chromes mTLS-Umstellung 2026

Ein Clientauthentifizierungszertifikat ist ein digitales Zertifikat , das die Identität eines Benutzers, Geräts, einer Arbeitslast oder eines Dienstes gegenüber einem Server nachweist, meist im Rahmen eines gegenseitigen TLS-Handshakes (mTLS). Die Änderung in Chrome aus dem Jahr 2026, die über das Chrome-Root-Programm eingeführt wird , ändert die Vertrauensanforderungen für öffentlich vertrauenswürdige Zertifikate. Gemäß diesen Anforderungen vertraut Chrome künftig keinen neu ausgestellten öffentlichen Zertifikaten mehr, die Server- und Clientauthentifizierung kombinieren. Neue Zertifikate, die unter konformen öffentlichen Hierarchien ausgestellt werden, sind auf die Serverauthentifizierung beschränkt, während ältere Zertifikate bis zu ihrem Ablaufdatum weiterhin gültig sind. Die Clientauthentifizierung erfolgt über private oder unternehmensweite PKI-Systeme.

Jahrelang haben viele Organisationen öffentlich vertrauenswürdige TLS-Zertifikate ( Transport Layer Security ) sowohl für die Server- als auch für die Clientauthentifizierung in mTLS-Bereitstellungen verwendet. Dieser Ansatz hat nun ausgedient.

Ab dem 15. Juni 2026 beschleunigen die durch Googles Chrome-Root-Programm eingeführten Änderungen die Trennung der öffentlichen Server- und Clientauthentifizierung in separate Public-Key-Infrastruktur-Hierarchien (PKI). Infolgedessen verzichten öffentlich vertrauenswürdige Zertifizierungsstellen (CAs) zunehmend auf die Ausstellung von Zertifikaten, die sowohl erweiterte Schlüsselverwendungen (EKUs) für die Server- als auch für die Clientauthentifizierung enthalten.

Der 15. Juni 2026 markiert den Stichtag für die Offenlegung neu deklarierter untergeordneter Zertifizierungsstellen; alle neu ausgestellten öffentlichen TLS-Teilnehmerzertifikate müssen ab dem 15. März 2027 gemäß Chrome Root Program Policy v1.8 ausschließlich die Server Authentication EKU enthalten.

Dies bedeutet nicht, dass Chrome mTLS abschafft. Mutual TLS bleibt ein wichtiger Sicherheitsmechanismus zur Authentifizierung von Nutzern, Geräten, Workloads und Diensten. Chrome treibt vielmehr den Wandel hin zu zweckspezifischen PKIs voran, bei denen öffentliche Zertifizierungsstellen die Serveridentität sicherstellen, während die Client-Authentifizierung über private PKIs oder dedizierte Unternehmens-Vertrauensinfrastrukturen erfolgt.

Für Organisationen, die zur Clientauthentifizierung weiterhin auf öffentlich vertrauenswürdige Zertifikate angewiesen sind, handelt es sich hierbei nicht um eine geringfügige Richtlinienaktualisierung. Es ist eine Änderung der Vertrauensarchitektur, die eine sorgfältige Planung erfordert, bevor die Erneuerungszyklen beginnen und dadurch versteckte Abhängigkeiten offenlegen.

Was hat Chrome tatsächlich verändert?

Chrome hat die Regeln für die Verwendung öffentlich vertrauenswürdiger Zertifikate geändert: Neue öffentliche TLS -Zertifikate dürfen nur noch die Serverauthentifizierungs-EKU bestätigen und können daher nicht mehr gleichzeitig als Clientauthentifizierungsnachweise dienen. In der Diskussion um dieses Thema wurde dies oft als „Ende von mTLS“ dargestellt, doch diese Charakterisierung ist irreführend.

Die Richtlinienänderungen des Chrome-Root-Programms zielen darauf ab, die Angriffsfläche der öffentlichen WebPKI durch die Förderung dedizierter TLS-Serverauthentifizierungshierarchien zu verringern. Ab dem 15. Juni 2026 müssen neu offengelegte untergeordnete Zertifizierungsstellen in Chrome-vertrauenswürdigen Hierarchien gemäß der Chrome-Root-Programmrichtlinie v1.8 ausschließlich die Server Authentication EKU (id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1) verwenden.

Die im Rahmen dieser Hierarchien ausgestellten Teilnehmerzertifikate dürfen ab dem 15. März 2027 nur noch für die Serverauthentifizierung verwendet werden, während bereits ausgestellte Zertifikate bis zu ihrem Ablaufdatum gültig bleiben.

Das Ziel ist einfach: Serveridentität von Clientidentität trennen.

Man kann es sich so vorstellen: Ein Serverzertifikat ist wie ein Schaufensterschild, das die Legitimität eines Geschäfts beweist, während ein Clientzertifikat wie ein Mitarbeiterausweis ist, der die Berechtigung zum Betreten des Geschäfts bestätigt. Chrome verlangt von jedem Zertifikat, genau eine dieser Funktionen zu erfüllen.

Historisch gesehen konnten manche öffentliche Zertifikate für beide Zwecke verwendet werden, da sie sowohl Serverauthentifizierungs- (OID 1.3.6.1.5.5.7.3.1) als auch Clientauthentifizierungs-EKUs (OID 1.3.6.1.5.5.7.3.2) enthielten. Dies war zwar praktisch, führte aber zu Mehrzweck-Anmeldeinformationen, die oft zu viele Berechtigungen besaßen und schwerer zu verwalten waren.

Die Richtlinie von Chrome drängt das Ökosystem in Richtung dedizierter Vertrauensmodelle, bei denen Zertifikate eine Rolle gut erfüllen, anstatt mehrere Rollen gleichzeitig.

Warum verabschieden sich öffentliche Zertifizierungsstellen von der Client-Authentifizierung?

Die Änderung steht im Einklang mit einer branchenweiten Bewegung hin zu zweckspezifischen Vertrauensarchitekturen.

Die Anforderungen an die Client-Authentifizierung unterscheiden sich erheblich von denen an die Authentifizierung öffentlicher Websites. Geräteidentität in Unternehmen , Workload-Authentifizierung, API-Authentifizierung und interne Dienstkommunikation erfordern oft eine strengere Kontrolle über Ausstellung, Widerruf, Lebenszyklusmanagement und Identitätsgovernance, als es öffentliche WebPKI ursprünglich vorgesehen hatte.

Let's Encrypt hat sich in diesem Punkt besonders deutlich geäußert. Die Organisation hat die Client-Authentifizierungs-EKU am 11. Februar 2026 aus ihrem Standardzertifikatsprofil entfernt und wird die Ausstellung von Client-Authentifizierungszertifikaten am 8. Juli 2026 vollständig einstellen, da viele Anwendungsfälle der Client-Authentifizierung besser durch private Zertifizierungsstellen abgedeckt werden. Diese Änderung steht in direktem Zusammenhang mit den Anforderungen des Chrome-Root-Programms an dedizierte Server-Authentifizierungshierarchien, wodurch private oder unternehmensweite PKIs zum bevorzugten Ansatz für die Client-Authentifizierung werden.

Die wichtigsten öffentlichen Zertifizierungsstellen, die im Rahmen des Chrome-Root-Programms tätig sind, verfolgen ähnliche Zeitpläne, wobei die meisten den Übergang vor dem Stichtag am 15. März 2027 abschließen werden.

Anders ausgedrückt: Chrome entfernt die Client-Authentifizierung nicht. Sie wird lediglich aus dem öffentlichen Vertrauenssystem herausgelöst.

Zeitleiste: Wichtige Termine, die Organisationen kennen sollten

Mehrere wichtige Meilensteine ​​betreffen Organisationen, die derzeit öffentliche Zertifikate zur Client-Authentifizierung verwenden.

Datum	Ändern
1. Oktober 2025	Let's Encrypt führt das temporäre tlsclient-Profil für Organisationen ein, die zusätzliche Migrationszeit benötigen.
11. Februar 2026	Let's Encrypt entfernt die Client-Authentifizierungs-EKU aus seinem Standardzertifikatsprofil.
May 13, 2026	Der Zugriff auf das tlsclient-Profil wird für neue Benutzer gesperrt; bestehende Benutzer können es bis zum 8. Juli 2026 weiter nutzen.
15. Juni 2026	Neu offengelegte untergeordnete Zertifizierungsstellen in Chrome-vertrauenswürdigen Hierarchien müssen ausschließlich die Server Authentication EKU (Chrome Root Program Policy v1.8) festlegen.
Juli 8, 2026	Let's Encrypt stellt die Ausstellung von Zertifikaten mit Client Authentication EKU über das tlsclient-Profil endgültig ein.
15. März 2027	Gemäß der Chrome-Root-Programmrichtlinie v1.8 müssen alle neu ausgestellten öffentlichen TLS-Teilnehmerzertifikate ausschließlich die Serverauthentifizierungs-EKU (id-kp-serverAuth) enthalten.

Für viele Organisationen werden die betrieblichen Auswirkungen nicht sofort sichtbar sein. Bestehende Zertifikate funktionieren in der Regel bis zu ihrem Ablaufdatum. Die eigentliche Störung tritt erst auf, wenn der Erneuerungszeitpunkt erreicht ist und neu ausgestellte Zertifikate die erwartete Client-Authentifizierungs-EKU nicht mehr enthalten.

Öffentliche PKI vs. private PKI: Die neue Realität

Die wichtigste architektonische Änderung ist die Trennung der Zertifikatsrollen.

Gebiet	Traditioneller Ansatz	Moderner Ansatz
Öffentliche TLS-Zertifikate	Serverauthentifizierung und Clientauthentifizierung zusammen	Nur Serverauthentifizierung
mTLS-Authentifizierung	Verwendet häufig öffentliche Zertifikate.	Nutzt eine private PKI oder eine dedizierte Client-Authentifizierungshierarchie
Vertrauensmodell	Gemeinsamer Vertrauenszweck	Zweckspezifische Vertrauensarchitektur
Zertifikatsverwaltung	Mehrzweckzertifikate	Spezielle Zertifikatsrollen
Sicherheitslage	Erweiterter Qualifikationsbereich	Verringerte Angriffsfläche und stärkere Durchsetzung von Richtlinien

Diese Änderung entspricht dem Prinzip der minimalen Rechtevergabe. Ein Zertifikat, das zur Authentifizierung einer öffentlichen Website bestimmt ist, sollte nicht automatisch als Anmeldeinformation für die Authentifizierung von Geräten, Benutzern, APIs oder internen Diensten dienen.

Durch die Trennung dieser Funktionen erlangen Organisationen eine stärkere Kontrolle über das Identitätsmanagement und verringern das Risiko des Missbrauchs von Zugangsdaten.

Was geht zuerst kaputt?

Zunächst geht nichts kaputt, und genau darin liegt das Risiko. Systeme funktionieren oft normal weiter, bis die Zertifikatserneuerung ansteht.

Eine mTLS-Bereitstellung kann heute einwandfrei funktionieren, da sie auf Zertifikaten basiert, die vor der Richtlinienänderung ausgestellt wurden. Wenn diese Zertifikate jedoch ablaufen und Administratoren versuchen, sie zu erneuern, enthält das Ersatzzertifikat möglicherweise nicht mehr die von der Anwendung erwartete Client-Authentifizierungs-EKU.

Dadurch entsteht ein gefährliches Szenario, in dem versteckte Abhängigkeiten unentdeckt bleiben, bis ein routinemäßiger Zertifikatsaustausch zu einem Ausfall führt.

Zu den Umgebungen, die am ehesten betroffen sein dürften, gehören:

• API-Gateways mit zertifikatbasierter Client-Authentifizierung
• Interne Kommunikation zwischen Diensten
• Geräteauthentifizierungsplattformen
• Partnerintegrationen mit mTLS
• Legacy-Workload Identität Architekturen
• Unternehmensanwendungen, die auf öffentliche Zertifikate für die Clientidentität angewiesen sind

Organisationen entdecken diese Abhängigkeiten oft erst, wenn eine Erneuerung fehlschlägt oder ein Handshake neue Zertifikate ablehnt.

Warum ist die Zertifikatsverwaltung wichtiger denn je?

Dieser Übergang unterstreicht eine Lektion, die PKI-Teams seit Jahren immer wieder betonen: Man kann nicht verwalten, was man nicht sieht.

Viele Organisationen verfügen zwar über einen ausgezeichneten Überblick über Website-Zertifikate, wissen aber kaum, wo Client-Zertifikate eingesetzt werden. Einige Client-Authentifizierungslösungen wurden vor Jahren implementiert und sind seither zu operativen Schwachstellen geworden.

Der erste Schritt jeder Migration sollte darin bestehen, Zertifikate mit der Client Authentication EKU zu identifizieren und festzustellen, ob sie von öffentlich vertrauenswürdigen Zertifizierungsstellen stammen. Dieser Ermittlungsprozess entspricht dem, was Praktiker zunehmend als kryptografische Stückliste (CBOM) bezeichnen – ein strukturiertes Inventar aller kryptografischen Assets, Algorithmen, Zertifikate und Schlüssel in der Umgebung. Die CBOM wird auch im Rahmen umfassenderer Planungsrahmen für Krypto-Agilität als empfohlene Vorgehensweise angesehen.

Sobald Zertifikate entdeckt wurden, können Organisationen sie in drei Kategorien einteilen:

• Öffentliche Website TLS
• Client-Authentifizierung
• Interne mTLS- und Workload-Identität

In vielen Umgebungen gehört nur die erste Kategorie tatsächlich in die öffentliche PKI.

Häufige Fehler, die Organisationen begehen

Ein weit verbreiteter Irrtum ist, dass Chrome die gegenseitige TLS-Verschlüsselung vollständig abschafft. Das ist falsch.

Die Richtlinien von Chrome beeinflussen, wie öffentliche Zertifizierungsstellen Zertifikate ausstellen. Mutual TLS wird weiterhin vollständig unterstützt und bleibt ein wichtiger Authentifizierungsmechanismus in Unternehmensumgebungen.

Ein weiterer Fehler besteht darin, erst zum Zeitpunkt der Zertifikatserneuerung die Abhängigkeiten zu untersuchen. Bis dahin kann die Zertifikatserneuerung bereits geschäftskritisch sein.

Manche Organisationen nutzen weiterhin öffentliche Zertifizierungsstellen für die interne Authentifizierung, einfach weil es vertraut ist. Allerdings war die öffentliche WebPKI nie dafür ausgelegt, unternehmensweite Geräteidentitäten, Workload-Identitäten oder interne Vertrauensbeziehungen in großem Umfang zu verwalten.

Der gegenwärtige Übergang verdeutlicht, warum diese Funktionen zunehmend in unternehmenskontrollierte PKI-Umgebungen gehören.

Bewährte Sicherheitspraktiken für die Zukunft

Die Richtung für die Branche wird immer deutlicher: Öffentliche PKI für öffentliches Vertrauen und private PKI für privates Vertrauen.

Öffentliche Zertifikate sollten primär zur Absicherung öffentlich zugänglicher Websites und internetbasierter Dienste verwendet werden. Clientauthentifizierung, Dienstidentität, Maschinenidentität und interne Workload-Authentifizierung sollten über unternehmensweite PKI-Systeme verwaltet werden, die speziell für diese Zwecke entwickelt wurden.

Organisationen sollten zudem der Automatisierung des Zertifikatslebenszyklus Priorität einräumen . Da die Gültigkeitsdauer von Zertifikaten branchenweit immer kürzer wird, sind manuelle Prozesse zunehmend schwer aufrechtzuerhalten.

Zertifikatsbestände sollten kontinuierlich überwacht, Erneuerungsprozesse automatisiert und private Schlüssel gegebenenfalls durch sichere Schlüsselverwaltungsmethoden wie Hardware-Sicherheitsmodule (HSMs) geschützt werden, die gemäß FIPS 140-3 validiert sind.

Diejenigen Organisationen, die diesen Übergang erfolgreich meistern, werden diejenigen sein, die ihn als Initiative zur Modernisierung des Vertrauens und nicht als Projekt zur Erneuerung von Zertifikaten betrachten.

Wie Verschlüsselungsberatung helfen kann

Für viele Organisationen besteht die Herausforderung nicht im Ersetzen eines Zertifikats, sondern in der Neugestaltung der Vertrauensarchitektur.

Encryption Consulting unterstützt Unternehmen bei der Modernisierung ihrer PKI-Umgebungen, der Trennung öffentlicher und privater Vertrauensmodelle und dem Aufbau skalierbarer Strategien für das Zertifikatslebenszyklusmanagement.

Mithilfe von Enterprise PKI Services können Unternehmen bestehende mTLS-Implementierungen bewerten, Abhängigkeiten von öffentlichen Zertifikaten identifizieren und private PKI-Architekturen entwerfen, die eine sichere Client-Authentifizierung und das Identitätsmanagement von Workloads unterstützen. Für Unternehmen, die Zertifizierungsstellenfunktionen auf Enterprise-Niveau benötigen, ohne den Aufwand für den Aufbau und Betrieb einer internen CA-Infrastruktur tragen zu müssen, bietet ein verwalteter privater CA-Service die erforderliche Ausstellung, das Lebenszyklusmanagement und die Richtlinienverwaltung, um die Client-Authentifizierung zukünftig zu gewährleisten.

Sobald die Architektur definiert ist, liegt die nächste Priorität in der operativen Transparenz der gesamten Zertifikatsumgebung und der Lebenszyklusautomatisierung, um mit den Erneuerungszyklen Schritt halten zu können.

CertSecure Manager bietet eine zentrale Zertifikatserkennung , Bestandsverwaltung, Überwachung und Lebenszyklusautomatisierung und hilft Unternehmen so, von den bevorstehenden Richtlinienänderungen betroffene Zertifikate zu identifizieren und Migrationsaktivitäten zu automatisieren, bevor Verlängerungsfristen ein operationelles Risiko darstellen.

Für Organisationen, die über die unmittelbare Migration hinausblicken und eine langfristige Vertrauensstrategie aufbauen müssen, bietet Encryption Consulting auch eine spezialisierte Beratung an.

Für Organisationen, die umfassendere Initiativen zur Modernisierung ihrer Vertrauensinfrastruktur planen, können unsere Beratungsdienste im Bereich Verschlüsselung dabei helfen, Zertifikatsmanagement, Workload-Identität, Krypto-Agilität und PKI-Governance in einen einheitlichen Fahrplan zu integrieren.

Fazit

Die für 2026 geplanten Richtlinienänderungen von Chrome bedeuten nicht das Ende von Mutual TLS. Sie bedeuten vielmehr das Ende der Nutzung von öffentlicher WebPKI als Universallösung für die Server- und Clientauthentifizierung.

Die Branche bewegt sich hin zu dedizierten Vertrauensarchitekturen , bei denen sich öffentliche Zertifizierungsstellen auf die Serverauthentifizierung konzentrieren und private PKI-Plattformen Clientidentitäten, Workload-Identitäten und unternehmensweite Vertrauensbeziehungen verwalten.

Organisationen, die ihren Zertifikatsbestand abbilden, Abhängigkeiten von der Client-Authentifizierung identifizieren und jetzt mit der Migration zu zweckspezifischen PKI-Modellen beginnen, werden spätere, störende Überraschungen bei der Zertifikatserneuerung vermeiden.

Die erfolgreichsten Migrationen werden nicht allein durch den Austausch von Zertifikaten erreicht. Sie werden vielmehr durch eine durchdachte Modernisierung der Vertrauensarchitektur vorangetrieben, die die Serveridentität von der Clientidentität trennt und Unternehmen auf die nächste Generation der PKI vorbereitet.