Client-Authentifizierungs-EKU: Was sich ab 2026 ändert

Digitale Zertifikate werden in IT-Umgebungen für sehr unterschiedliche Zwecke eingesetzt. Damit ein Zertifikat nur im vorgesehenen Kontext genutzt werden kann, enthält es Einschränkungen wie die Extended Key Usage (EKU).
Im Fokus dieses Beitrags steht die Client-Authentifizierungs-EKU (clientAuth). Sie ist für Szenarien gedacht, in denen sich ein Client gegenüber einem Server authentifiziert – zum Beispiel bei Mutual TLS (mTLS), in VPN-Umgebungen oder bei Geräte-/User-Authentifizierung.

In den letzten Jahren war es bei manchen öffentlich vertrauenswürdigen TLS-Serverzertifikaten üblich, neben Server Authentication (serverAuth) auch Client Authentication (clientAuth) im EKU-Feld zu führen. Für klassisches HTTPS im Browser-Kontext ist clientAuth typischerweise nicht erforderlich. Genau solche „gemischten Profile“ werden nach aktueller Planung und Ankündigungen im Umfeld von Root-Programmen und CAs zunehmend vermieden. Unternehmen sollten deshalb prüfen, ob sie betroffen sind, und ihre Zertifikatsprofile sowie Prozesse rechtzeitig sauber trennen.

Das Wichtigste in 30 Sekunden

Was ändert sich?
Öffentlich vertrauenswürdige TLS-Serverzertifikate sollen künftig ohne clientAuth ausgestellt bzw. akzeptiert werden (Profiltrennung).

Wer ist betroffen?
Vor allem Organisationen mit Public TLS-Zertifikaten (Websites/öffentliche APIs), in denen clientAuth zusätzlich enthalten ist.

Was tun?
Inventarisieren → EKU prüfen → Server-/Client-Zertifikate trennen → Reissue/Erneuerung planen → Automatisierung/Policies sauber setzen.

Was ist eine Extended Key Usage?

Die Extended Key Usage (EKU) ist eine X.509-Erweiterung, die festlegt, wofür ein Zertifikat verwendet werden darf. Anwendungen und Betriebssysteme können EKUs auswerten, um zu prüfen, ob ein Zertifikat für einen bestimmten Zweck zulässig ist.
Typische EKUs sind:

• Server Authentication (serverAuth): für TLS-Webserver/HTTPS-Endpunkte
• Client Authentication (clientAuth): für Client-Identitäten (z. B. mTLS-Client)
• Code Signing: zum Signieren von Software
• E-Mail-Protection: z. B. für S/MIME

Wichtig: EKU ist ein Mechanismus zur Zweckbindung. Je nach Software-Stack wird EKU strenger oder weniger streng geprüft.

Die Rolle der Client-Authentifizierungs-EKU

Die Client Authentication EKU trägt die Objektkennung 1.3.6.1.5.5.7.3.2. Sie signalisiert: Dieses Zertifikat darf zur Authentifizierung eines Clients gegenüber einem Server eingesetzt werden.
In Unternehmensumgebungen wird diese EKU häufig genutzt, um Zero-Trust-Konzepte umzusetzen, zum Beispiel bei:

• mTLS (Mutual TLS) für Service-zu-Service-Kommunikation oder API-Zugänge
• VPN-Authentifizierung (Client-Zertifikate)
• Geräte-/Benutzerzertifikate in Zero-Trust- oder MDM-Kontexten
• Interne Plattformen, die Clientzertifikate als Identitätsmerkmal nutzen

In Teilen der Praxis wurden öffentlich vertrauenswürdige TLS-Serverzertifikate zusätzlich mit clientAuth ausgestellt. Das ist für Browser-basiertes HTTPS typischerweise nicht erforderlich und kann insbesondere dort Fragen aufwerfen, wo EKUs strikt validiert werden. Die anstehenden Änderungen zielen darauf ab, Zertifikatsprofile eindeutiger zu machen.

Was ändert sich bei öffentlich vertrauenswürdigen TLS-Serverzertifikaten?

In Root-Programm- und Browser-Kontexten wird seit einiger Zeit stärker auf eindeutige Zertifikatsprofile geachtet: Ein öffentlich vertrauenswürdiges TLS-Serverzertifikat soll primär eindeutig als Serverzertifikat erkennbar sein – typischerweise also serverAuth enthalten, aber keine zusätzlichen EKUs, die eher zu Client-Identitäten passen.

Für Unternehmen ist dabei entscheidend:

• Es geht vor allem um öffentlich vertrauenswürdige Zertifikate (Public CA / Browser Trust) im Web-/HTTPS-Kontext
• Private PKIs oder rein interne mTLS-Landschaften sind nicht automatisch im gleichen Maß betroffen – profitieren aber ebenfalls von sauber getrennten Profilen (weniger Missverständnisse, klarere Policies, einfachere Audits)

Bin ich betroffen?

Eine Frage, die sich viele sofort stellen – kurz und knapp:

Wahrscheinlich ja, wenn …

• Sie öffentlich vertrauenswürdige TLS-Zertifikate für Websites oder öffentliche API-Endpunkte nutzen und/oder
• Ihre Serverzertifikate serverAuth + clientAuth (oder clientAuth zusätzlich) enthalten.

Eher nicht direkt, wenn …

• Sie nur private CA/Private PKI für interne mTLS-Kommunikation nutzen und/oder
• keine Browser-/Public-Trust-Anforderungen greifen

Auswirkungen auf Unternehmen und Organisationen

Die Änderungen sind vor allem dort relevant, wo öffentlich vertrauenswürdige TLS-Serverzertifikate im Browser-/Public-Trust-Kontext eingesetzt werden. Gleichzeitig ist die Umstellung ein guter Anlass, Zertifikatsrollen (Server vs. Client) und Automatisierung in der eigenen PKI zu überprüfen.

Websites & öffentliche APIs

Wenn TLS-Serverzertifikate im Browser-/Public-Trust-Kontext künftig strenger validiert werden, können „gemischte EKU-Profile“ zum Risiko werden. Praktisch bedeutet das: Betroffene Zertifikate sollten rechtzeitig neu ausgestellt (Reissue) oder bei der nächsten Erneuerung entsprechend bereinigt werden.

mTLS-Umgebungen

mTLS bleibt mTLS. Entscheidend ist die Trennung der Rollen

1. Serverseite: Serverzertifikat (serverAuth)
2. Clientseite: Clientzertifikat (clientAuth)

Wer bisher versucht hat, einen Zweck „mit einem Zertifikat für alles“ abzudecken, sollte die Rollen künftig sauber trennen (was in vielen Security-Architekturen ohnehin Best Practice ist).

Prozesse & Tooling

Organisationen mit automatisierten Zertifikatsprozessen (CLM, ACME, zentrale Templates/Policies) können die Umstellung meist kontrolliert durchführen. In manuellen Umgebungen steigt das Risiko, dass einzelne Zertifikate oder Konfigurationen übersehen werden.

Was Sie jetzt tun sollten: Eine Handlungsempfehlung

Der erste Schritt zur Anpassung an die kommenden Vorgaben besteht in einer Bestandsaufnahme. Unternehmen sollten ihre öffentlich vertrauenswürdigen TLS-Zertifikate daraufhin prüfen, ob sie die Client Authentication EKU (clientAuth) enthalten. Hierzu lassen sich gängige Tools wie OpenSSL oder professionelle CLM-Systeme nutzen.

Im nächsten Schritt gilt es zu identifizieren, welche Dienste tatsächlich Client-Authentifizierung benötigen – etwa bei mTLS-Zugängen, VPNs oder der Authentifizierung interner APIs und Dienste. Wo Client-Authentifizierung erforderlich ist, sollten die dafür genutzten Zertifikate künftig klar von öffentlichen TLS-Serverzertifikaten getrennt werden (Serverzertifikate für serverAuth, Clientzertifikate für clientAuth).

Setzen Sie bei der Umsetzung auf Automatisierung: Moderne Lösungen wie KeyTalk, Venafi oder ACME-basierte Services können die Ausstellung, Erneuerung und Verteilung von Zertifikaten mit passenden EKU-Profilen zentral steuern. Das reduziert manuelle Fehler, spart Zeit und erhöht die Transparenz.

Abschließend sollten betroffene TLS-Serverzertifikate im Browser-/Public-Trust-Kontext neu ausgestellt (Reissue) werden, wenn sie unnötigerweise clientAuth enthalten. In vielen Fällen reicht ein Reissue aus, um das Zertifikatsprofil entsprechend zu bereinigen.

Zeitplan & Stichtage

(Stand: Dezember 2025)

Nach aktuellen Veröffentlichungen rund um das Chrome Root Program gilt für den Browser-/Public-Trust-Kontext: Chrome (und Software, die auf dem Chrome Root Store basiert) plant ab dem 15. Juni 2026 TLS-Serverzertifikate nicht mehr zu akzeptieren, wenn sie im EKU-Feld neben serverAuth auch clientAuth enthalten. [Quelle: Chrome Root Program Policy]

Parallel dazu passen öffentliche Zertifizierungsstellen (CAs) ihre Ausstellungspraxis an. Beispielhaft:

• DigiCert: clientAuth wird seit 1. Oktober 2025 nicht mehr standardmäßig eingebunden; ab 1. Mai 2026 ist clientAuth in neu ausgestellten DigiCert Public TLS-Zertifikaten nicht mehr verfügbar. [Quelle: knowledge.digicert.com]
• Sectigo: clientAuth wird ab 15. Mai 2026 aus neu ausgestellten SSL/TLS-Zertifikaten entfernt (phasenweise Umstellung ab 2025). [Quelle: sectigo.com]
• Let’s Encrypt: kündigt an, clientAuth ab 2026 nicht mehr in Zertifikaten zu führen (Details je nach Umsetzung/Timeline). [Quelle: letsencrypt.org]

Wichtig: Die konkreten Stichtage und Übergangsregeln unterscheiden sich je CA. Für Planung und Compliance lohnt sich ein Abgleich mit den jeweiligen CA-Hinweisen und dem eigenen Zertifikatsbestand.

Es ist Zeit für saubere Zertifikatsprofile

Die Entwicklung hin zu klar getrennten Zertifikatszwecken sorgt langfristig für mehr Eindeutigkeit in Zertifikatslandschaften und reduziert typische Fehlkonfigurationen. Unternehmen, die heute EKUs in ihren Public TLS-Serverzertifikaten prüfen und Rollen sauber trennen, senken das Risiko von späteren Kompatibilitätsproblemen und schaffen eine wartbare Grundlage für mTLS- und Zero-Trust-Architekturen.