Digitale Zertifikate werden in IT-Umgebungen f\u00fcr sehr unterschiedliche Zwecke eingesetzt. Damit ein Zertifikat nur im vorgesehenen Kontext genutzt werden kann, enth\u00e4lt es Einschr\u00e4nkungen wie die Extended Key Usage (EKU).
\nIm Fokus dieses Beitrags steht die Client-Authentifizierungs-EKU (clientAuth). Sie ist f\u00fcr Szenarien gedacht, in denen sich ein Client gegen\u00fcber einem Server authentifiziert \u2013 zum Beispiel bei Mutual TLS (mTLS), in VPN-Umgebungen oder bei Ger\u00e4te-\/User-Authentifizierung.<\/p>\n
In den letzten Jahren war es bei manchen \u00f6ffentlich vertrauensw\u00fcrdigen TLS-Serverzertifikaten \u00fcblich, neben Server Authentication (serverAuth) auch Client Authentication (clientAuth) im EKU-Feld zu f\u00fchren. F\u00fcr klassisches HTTPS im Browser-Kontext ist clientAuth typischerweise nicht erforderlich. Genau solche \u201egemischten Profile\u201c werden nach aktueller Planung und Ank\u00fcndigungen im Umfeld von Root-Programmen und CAs zunehmend vermieden. Unternehmen sollten deshalb pr\u00fcfen, ob sie betroffen sind, und ihre Zertifikatsprofile sowie Prozesse rechtzeitig sauber trennen.<\/p>\n
Das Wichtigste in 30 Sekunden<\/strong><\/p>\n Was \u00e4ndert sich? Wer ist betroffen? Was tun? <\/p>\n Die Extended Key Usage (EKU) ist eine X.509-Erweiterung, die festlegt, wof\u00fcr ein Zertifikat verwendet werden darf. Anwendungen und Betriebssysteme k\u00f6nnen EKUs auswerten, um zu pr\u00fcfen, ob ein Zertifikat f\u00fcr einen bestimmten Zweck zul\u00e4ssig ist. Wichtig: EKU ist ein Mechanismus zur Zweckbindung. Je nach Software-Stack wird EKU strenger oder weniger streng gepr\u00fcft.<\/em><\/p>\n <\/p>\n Die Client Authentication EKU tr\u00e4gt die Objektkennung 1.3.6.1.5.5.7.3.2. Sie signalisiert: Dieses Zertifikat darf zur Authentifizierung eines Clients gegen\u00fcber einem Server eingesetzt werden. In Teilen der Praxis wurden \u00f6ffentlich vertrauensw\u00fcrdige TLS-Serverzertifikate zus\u00e4tzlich mit clientAuth ausgestellt. Das ist f\u00fcr Browser-basiertes HTTPS typischerweise nicht erforderlich und kann insbesondere dort Fragen aufwerfen, wo EKUs strikt validiert werden. Die anstehenden \u00c4nderungen zielen darauf ab, Zertifikatsprofile eindeutiger zu machen.<\/p>\n <\/p>\n In Root-Programm- und Browser-Kontexten wird seit einiger Zeit st\u00e4rker auf eindeutige Zertifikatsprofile geachtet: Ein \u00f6ffentlich vertrauensw\u00fcrdiges TLS-Serverzertifikat soll prim\u00e4r eindeutig als Serverzertifikat erkennbar sein \u2013 typischerweise also serverAuth enthalten, aber keine zus\u00e4tzlichen EKUs, die eher zu Client-Identit\u00e4ten passen.<\/p>\n F\u00fcr Unternehmen ist dabei entscheidend:<\/p>\n Eine Frage, die sich viele sofort stellen \u2013 kurz und knapp:<\/p>\n Wahrscheinlich ja, wenn \u2026<\/strong><\/p>\n <\/p>\n Eher nicht direkt, wenn \u2026<\/strong><\/p>\n <\/p>\n Die \u00c4nderungen sind vor allem dort relevant, wo \u00f6ffentlich vertrauensw\u00fcrdige 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 \u00fcberpr\u00fcfen.<\/p>\n Wenn TLS-Serverzertifikate im Browser-\/Public-Trust-Kontext k\u00fcnftig strenger validiert werden, k\u00f6nnen \u201egemischte EKU-Profile\u201c zum Risiko werden. Praktisch bedeutet das: Betroffene Zertifikate sollten rechtzeitig neu ausgestellt (Reissue) oder bei der n\u00e4chsten Erneuerung entsprechend bereinigt werden.<\/p>\n mTLS bleibt mTLS. Entscheidend ist die Trennung der Rollen<\/p>\n Wer bisher versucht hat, einen Zweck \u201emit einem Zertifikat f\u00fcr alles\u201c abzudecken, sollte die Rollen k\u00fcnftig sauber trennen (was in vielen Security-Architekturen ohnehin Best Practice ist).<\/p>\n Organisationen mit automatisierten Zertifikatsprozessen (CLM, ACME, zentrale Templates\/Policies) k\u00f6nnen die Umstellung meist kontrolliert durchf\u00fchren. In manuellen Umgebungen steigt das Risiko, dass einzelne Zertifikate oder Konfigurationen \u00fcbersehen werden.<\/p>\n <\/p>\n Der erste Schritt zur Anpassung an die kommenden Vorgaben besteht in einer Bestandsaufnahme. Unternehmen sollten ihre \u00f6ffentlich vertrauensw\u00fcrdigen TLS-Zertifikate daraufhin pr\u00fcfen, ob sie die Client Authentication EKU (clientAuth) enthalten. Hierzu lassen sich g\u00e4ngige Tools wie OpenSSL oder professionelle CLM-Systeme nutzen.<\/p>\n Im n\u00e4chsten Schritt gilt es zu identifizieren, welche Dienste tats\u00e4chlich Client-Authentifizierung ben\u00f6tigen \u2013 etwa bei mTLS-Zug\u00e4ngen, VPNs oder der Authentifizierung interner APIs und Dienste. Wo Client-Authentifizierung erforderlich ist, sollten die daf\u00fcr genutzten Zertifikate k\u00fcnftig klar von \u00f6ffentlichen TLS-Serverzertifikaten getrennt werden (Serverzertifikate f\u00fcr serverAuth, Clientzertifikate f\u00fcr clientAuth).<\/p>\n Setzen Sie bei der Umsetzung auf Automatisierung: Moderne L\u00f6sungen wie KeyTalk<\/a>, Venafi oder ACME-basierte Services<\/a> k\u00f6nnen die Ausstellung, Erneuerung und Verteilung von Zertifikaten mit passenden EKU-Profilen zentral steuern. Das reduziert manuelle Fehler, spart Zeit und erh\u00f6ht die Transparenz.<\/p>\n Abschlie\u00dfend sollten betroffene TLS-Serverzertifikate im Browser-\/Public-Trust-Kontext neu ausgestellt (Reissue) werden, wenn sie unn\u00f6tigerweise clientAuth enthalten. In vielen F\u00e4llen reicht ein Reissue aus, um das Zertifikatsprofil entsprechend zu bereinigen.<\/p>\n <\/p>\n (Stand: Dezember 2025)<\/em><\/p>\n Nach aktuellen Ver\u00f6ffentlichungen rund um das Chrome Root Program gilt f\u00fcr 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<\/a>]<\/p>\n Parallel dazu passen \u00f6ffentliche Zertifizierungsstellen (CAs) ihre Ausstellungspraxis an. Beispielhaft:<\/p>\n Wichtig: Die konkreten Stichtage und \u00dcbergangsregeln unterscheiden sich je CA. F\u00fcr Planung und Compliance lohnt sich ein Abgleich mit den jeweiligen CA-Hinweisen und dem eigenen Zertifikatsbestand.<\/p>\n <\/p>\n Die Entwicklung hin zu klar getrennten Zertifikatszwecken sorgt langfristig f\u00fcr mehr Eindeutigkeit in Zertifikatslandschaften und reduziert typische Fehlkonfigurationen. Unternehmen, die heute EKUs in ihren Public TLS-Serverzertifikaten pr\u00fcfen und Rollen sauber trennen, senken das Risiko von sp\u00e4teren Kompatibilit\u00e4tsproblemen und schaffen eine wartbare Grundlage f\u00fcr mTLS- und Zero-Trust-Architekturen.<\/p>\n
\n\u00d6ffentlich vertrauensw\u00fcrdige TLS-Serverzertifikate sollen k\u00fcnftig ohne clientAuth ausgestellt bzw. akzeptiert werden (Profiltrennung).<\/em><\/p>\n
\nVor allem Organisationen mit Public TLS-Zertifikaten (Websites\/\u00f6ffentliche APIs), in denen clientAuth zus\u00e4tzlich enthalten ist.<\/em><\/p>\n
\nInventarisieren \u2192 EKU pr\u00fcfen \u2192 Server-\/Client-Zertifikate trennen \u2192 Reissue\/Erneuerung planen \u2192 Automatisierung\/Policies sauber setzen.<\/em><\/p>\nWas ist eine Extended Key Usage?<\/h2>\n
\nTypische EKUs sind:<\/p>\n\n
Die Rolle der Client-Authentifizierungs-EKU<\/h2>\n
\nIn Unternehmensumgebungen wird diese EKU h\u00e4ufig genutzt, um Zero-Trust-Konzepte<\/a> umzusetzen, zum Beispiel bei:<\/p>\n\n
Was \u00e4ndert sich bei \u00f6ffentlich vertrauensw\u00fcrdigen TLS-Serverzertifikaten?<\/h3>\n
\n
Bin ich betroffen?<\/h3>\n
\n
\n
Auswirkungen auf Unternehmen und Organisationen<\/h2>\n
Websites & \u00f6ffentliche APIs<\/h3>\n
mTLS-Umgebungen<\/h3>\n
\n
Prozesse & Tooling<\/h3>\n
Was Sie jetzt tun sollten: Eine Handlungsempfehlung<\/h2>\n
Zeitplan & Stichtage<\/h2>\n
\n
Es ist Zeit f\u00fcr saubere Zertifikatsprofile<\/h2>\n