Client-Authentifizierungs-EKU ausgelaufen

Zusammenfassung

In diesem Blogbeitrag geht es um die bevorstehenden Änderungen hinsichtlich der Entfernung der Client Authentication Extended Key Usage (EKU) aus öffentlich vertrauenswürdigen SSL/TLS-Zertifikaten . Diese Verschiebung ist auf Sicherheitsbedenken und die Notwendigkeit klarerer Rollen bei kryptografischen Vorgängen zurückzuführen.

Ab September 2025 werden die großen Zertifizierungsstellen (CAs) damit beginnen, die Client Authentication EKU aus der öffentlichen Zertifikatsausstellung auslaufen zu lassen. Diese Erweiterung wird Mitte 2026 endgültig eingestellt.

Das Hauptziel dieser Änderungen besteht laut CA/B-Forum darin, die Sicherheitsrisiken von Dual-Purpose-Zertifikaten zu reduzieren und strengere Richtlinien für deren Verwendung durchzusetzen. Unternehmen, die auf gegenseitige TLS- oder Client-Authentifizierung setzen, müssen dedizierte Client-Zertifikate einsetzen, um Compliance zu gewährleisten und einen sicheren Betrieb aufrechtzuerhalten. Dieser Blogbeitrag beschreibt die Auswirkungen dieser Änderungen, die damit verbundenen Sicherheitsvorteile und konkrete Schritte zur Vorbereitung von Unternehmen auf die Umstellung.

 

Einführung

Sicherheit und Compliance sind für Unternehmen, die kryptografische Zertifikate zur Authentifizierung und Kommunikation nutzen, von größter Bedeutung. Die Entfernung der Client Authentication Extended Key Usage (EKU) aus SSL-Zertifikaten verändert die Nutzung dieser Zertifikate, insbesondere für Mutual TLS ( mTLS )-Szenarien. Dieser Blogbeitrag bietet einen umfassenden Überblick über die Client Authentication EKU, ihre Auswirkungen und den Zeitplan für die schrittweise Einführung. Durch das Verständnis dieser bevorstehenden Änderungen können Unternehmen die notwendigen Maßnahmen ergreifen, um Compliance und Sicherheit zu gewährleisten und gleichzeitig die Transparenz ihrer Zertifikatsverwaltung zu verbessern.

 

Was ist die erweiterte Schlüsselverwendung (EKU) für die Clientauthentifizierung?

Die Clientauthentifizierung EKU (Extended Key Usage) ist eine Zertifikatserweiterung, die ein digitales Zertifikat zur Authentifizierung eines Clients (z. B. eines Benutzers oder Geräts) gegenüber einem Server bezeichnet und häufig in Szenarien mit gegenseitigem TLS ( mTLS ) verwendet wird.

Es handelt sich um eine Funktion, die digitalen Zertifikaten hinzugefügt wird und die Verwendung eines öffentlichen Schlüssels angibt. Sie erstellt eine klare Liste der zulässigen Verwendungszwecke und stellt sicher, dass der Schlüssel nur für bestimmte kryptografische Aufgaben verwendet wird. Die zulässigen Verwendungszwecke werden durch eindeutige Nummern, sogenannte Object Identifiers (OIDs), identifiziert, die den jeweiligen Zweck kategorisieren, z. B. Codesignatur, Server-Authentifizierung, Client-Authentifizierung oder sichere E-Mail.

Bei der Überprüfung eines Zertifikats wird die OID anhand der EKU ermittelt. Durch die Einbindung der EKU-Erweiterung schränkt eine Zertifizierungsstelle (CA) den Verwendungszweck des Zertifikats ein und verknüpft jeden Zweck mit einer bestimmten OID. Hier einige Beispiele:

• TLS-Webserver-Authentifizierung : Das Zertifikat kann zur Verifizierung eines Servers verwendet werden, beispielsweise für eine HTTPS-Website. Die OID für die Serverauthentifizierung lautet 1.3.6.1.5.5.7.3.1 .
• TLS-Webclient-Authentifizierung : Das Zertifikat kann von einem Client verwendet werden, um sich gegenüber einem Server zu verifizieren, z. B. bei gegenseitigem TLS. Die OID für die Client-Authentifizierung lautet 1.3.6.1.5.5.7.3.2 .

Normalerweise benötigen Browser und Server zum Einrichten einer sicheren HTTPS-Verbindung nur die ServerAuth -EKU. Viele TLS-Serverzertifikate enthielten jedoch in der Vergangenheit sowohl die ServerAuth- als auch die ClientAuth -EKU.

 

 

EKU-Nutzung in PKI

• EKUs schränken die zulässigen Rollen eines Zertifikats ein, beispielsweise Serverauthentifizierung, Clientauthentifizierung, Codesignatur oder E-Mail-Schutz.
• Wenn eine Client-Authentifizierung erforderlich ist (z. B. mTLS ), signalisiert das Vorhandensein der clientAuth -EKU einem System, dass das Zertifikat für diesen Zweck vertrauenswürdig ist.
• In der Vergangenheit enthielten einige Server-TLS-Zertifikate sowohl ServerAuth- als auch ClientAuth -EKUs. Diese Vorgehensweise wird jedoch nicht mehr unterstützt, um Sicherheitsrisiken zu verringern und kryptografische Rollen zu klären.

 

Branchenänderungen

• Ab 2025–2026 werden die großen Zertifizierungsstellen und Browser-Root-Programme (wie Google Chrome) eine Trennung der EKUs für die Server- und Client-Authentifizierung erfordern . Das bedeutet, dass öffentliche TLS-Zertifikate nur über die EKU „serverAuth“ und nicht „clientAuth“ verfügen sollten , um Missbrauch zu verhindern und die Sicherheit zu verbessern.
• Organisationen, die eine Client-Authentifizierung benötigen, brauchen jetzt dedizierte Client-Zertifikate mit der ClientAuth -EKU.

 

 

Auswirkungen der Entfernung der Client-Authentifizierungs-EKU auf SSL-Zertifikate

Das Entfernen der Client Authentication EKU aus SSL-Zertifikaten bedeutet, dass zukünftige öffentliche Serverzertifikate ausschließlich für die Serverauthentifizierung und nicht für clientseitige Zwecke wie gegenseitiges TLS ( mTLS ) verwendet werden.

 

Auswirkungen auf die Verwendung von SSL-Zertifikaten

• Nach Mitte 2025 ausgestellte Serverzertifikate enthalten nur die ServerAuth- EKU, wodurch eine mehrdeutige oder unsichere Verwendung als Client-Authentifizierungsdaten verhindert wird.
• Vorhandene Zertifikate (vor Ablauf der Fristen ausgestellt) behalten ihre Gültigkeit und werden nicht rückwirkend widerrufen.
• Standard-HTTPS-Webserver sind davon nicht betroffen, da Browser (wie Chrome und Firefox) nur die Serverauthentifizierung überprüfen und die ClientAuth- EKU für den Websitezugriff ignorieren.
• Für Umgebungen, die auf mTLS oder Client-/Geräteauthentifizierung mit öffentlichen SSL-Zertifikaten basieren, wird zukünftig ein separates Client-Authentifizierungszertifikat benötigt.

Vorteile für Sicherheit und Compliance

• Reduziert das Risiko von Missbrauch und unbeabsichtigter Doppelnutzung und verbessert die Trennung zwischen öffentlichem Internet und internen PKI-Infrastrukturen.
• Richtet alle Zertifizierungsstellen (CAs) und Browser nach strengeren Richtlinien aus, die sichere Zertifikate für einen einzigen Zweck unterstützen.

Schritte für Organisationen

• Überprüfen Sie die Zertifikatsbestände, um festzustellen, welche Systeme für die Client-Authentifizierung auf Dual-Use- /Server-Zertifikate angewiesen sind.
• Aktualisieren Sie Systeme, um dedizierte Client-Zertifikate (mit ClientAuth EKU) für gegenseitiges TLS, Geräteauthentifizierung oder Server-zu-Server-Verbindungen zu verwenden.
• Passen Sie die Prozesse/Dokumentation für Zertifikatsanforderungen an, damit zukünftige Erneuerungen den neuen Richtlinien entsprechen und Serviceunterbrechungen vermieden werden.

 

Effekttabelle

Anwendungsfall	Änderung nach EKU-Entfernung	Erforderliche Aktion
HTTPS-Websites	Keine Auswirkungen; Standard-SSL wird fortgesetzt	Keiner
Gegenseitiges TLS ( mTLS )	Serverzertifikate können Clients nicht authentifizieren	Wechseln Sie zu dedizierten Client-Zertifikaten
Legacy-/Unternehmenssysteme	Dual-Use-Zertifikate abgelehnt; mögliche Inkompatibilität	Aktualisieren Sie Systeme, verwenden Sie dedizierte Client-Zertifikate

 

Die Entfernung der EKU zur Client-Authentifizierung ist ein sicherheitsorientierter Schritt, um sicherzustellen, dass SSL-Zertifikate für den vorgesehenen Zweck verwendet werden. Die Auswirkungen auf die meisten Benutzer sind minimal, mit Ausnahme derjenigen, die auf mTLS oder gemischte Authentifizierungsumgebungen angewiesen sind.

 

Wann stellen CAs keine Zertifikate mehr mit Client Authentication EKU aus?

Zertifizierungsstellen (CAs) werden ab September 2025 damit beginnen, SSL/TLS-Zertifikate mit der Client Authentication EKU auslaufen zu lassen . Die endgültigen Stichtage liegen je nach CA Mitte 2026.

Wichtige CA-Zeitleisten-Highlights

• 15. September 2025: Die meisten großen Zertifizierungsstellen, darunter Sectigo und Trustico , werden die Client-Authentifizierungs-EKU nicht mehr standardmäßig einbinden . in neuen SSL-Zertifikaten.
• 1. Oktober 2025: DigiCert stellt standardmäßig keine öffentlichen TLS-Zertifikate mehr mit der ClientAuth- EKU aus. Sonderwünsche können bis zum 1. Mai 2026 berücksichtigt werden. Danach dürfen keine öffentlichen Zertifikate mehr die ClientAuth- EKU enthalten.
• 13.–15. Mai 2026: Letzte branchenweite Fristen; alle großen Zertifizierungsstellen (einschließlich Let’s Encrypt, Sectigo , DigiCert und Trustico ) werden die Client Authentication EKU dauerhaft aus der Ausstellung neuer öffentlicher SSL/TLS-Zertifikate entfernen, einschließlich Verlängerungen und Neuausstellungen.
• 15. Juni 2026: Das Root-Programm von Google Chrome vertraut ab diesem Datum nur noch öffentlichen SSL-Zertifikaten mit ServerAuth EKU und lehnt alle Zertifikate mit ClientAuth EKU ab.

 

Übersichtstabelle

CA-Name	Standard-Enddatum	Harte Frist
Sectigo	15. September 2025	15. Mai 2026
DigiCert	1. Oktober 2025	1. Mai 2026
Lass uns verschlüsseln	Anfang 2026	13. Mai 2026
Trustico	15. September 2025	15. Mai 2026

 

Nach diesen Fristen werden keine neuen oder erneuerten öffentlichen SSL/TLS-Zertifikate von großen Zertifizierungsstellen mehr die Client Authentication EKU enthalten, was den branchenweiten Übergang markiert.

 

 

 

Welche Sicherheitsvorteile ergeben sich durch das Entfernen von ClientAuth EKU?

Laut dem CA/B-Forum bringt das Entfernen der ClientAuth EKU aus öffentlich vertrauenswürdigen SSL-Zertifikaten mehrere wichtige Sicherheitsvorteile mit sich, da die Spezifität des Zertifikatszwecks erzwungen und das Risiko eines Missbrauchs oder einer Fehlkonfiguration verringert wird.

Trennung von Vertrauensrollen

• Öffentliche Serverzertifikate werden ausschließlich zur Serverauthentifizierung verwendet, nicht zur Client- oder Geräteauthentifizierung.
• Dadurch wird die Wahrscheinlichkeit minimiert, dass Zertifikate über ihren eigentlichen Zweck hinaus zweckentfremdet werden, und das Prinzip der geringsten Privilegien wird eingehalten.

Reduziertes Risiko einer Fehlkonfiguration

• Einige Systeme akzeptierten bisher jedes Zertifikat mit einer ClientAuth EKU zur Client-Authentifizierung, was zu einem möglichen unbefugten Zugriff führen konnte, wenn einem öffentlichen Serverzertifikat fälschlicherweise vertraut wurde.
• Durch die Beschränkung der EKUs auf ihre vorgesehenen Verwendungszwecke wird die PKI-Architektur übersichtlicher und robuster für Wartung und Audits.

Verbesserte PKI-Hygiene und Compliance

• Durch die Durchsetzung separater Zertifikatshierarchien für Server- und Clientrollen werden Zertifizierungsstellen (CAs) an die Browseranforderungen und modernen PKI-Standards angepasst.
• Reduziert die Komplexität und Angriffsfläche von Mehrzweckzertifikaten und erleichtert so die Verwaltung und Sicherung öffentlicher und privater PKI-Bereitstellungen.

Verhinderung des Missbrauchs von Mehrzweckzertifikaten

• Gemischt genutzte Zertifikate (mit ServerAuth- und ClientAuth -EKUs) können missbraucht werden, wenn sie in unbeabsichtigten Authentifizierungsschemata verwendet werden, was möglicherweise eine laterale Bewegung oder eine Rechteausweitung erleichtert.
• Durch die Anforderung separater Zertifikate für jeden Zweck können Organisationen sensible Zugriffsszenarien besser überwachen, prüfen und kontrollieren.

 

Übersichtstabelle

Sicherheitsvorteil	Beschreibung
Rollentrennung (geringste Privilegien)	Verhindert die Verwendung von Zertifikaten außerhalb des Geltungsbereichs
Reduziert das Risiko einer Fehlkonfiguration	Beseitigt versehentliche Client/Server-EKU-Überlappungen
Verbessert die PKI-Architektur	Ermöglicht eine klare PKI-Trennung und Richtliniendurchsetzung
Verringert die Angriffsfläche	Verhindert unbeabsichtigten Zugriff über Mehrzweckzertifikate

 

Zusammenfassend lässt sich sagen, dass das Entfernen von ClientAuth EKU aus Server-SSL-Zertifikaten die Sicherheit erhöht, indem die Zertifikatsverwendung geklärt, die Einhaltung von Vorschriften erzwungen und das Risiko verringert wird, dass öffentliche Zertifikate für vertrauliche Client-Authentifizierungsszenarien missbraucht werden.

 

Wie bereiten Sie Ihre Systeme auf den Zeitplan für die EKU-Abkündigung vor?

Abschaffung der Client Authentication EKU vorzubereiten , sollten Unternehmen proaktive Schritte unternehmen, um einen weiterhin sicheren Betrieb und die Einhaltung der Vorschriften bis zu den Fristen 2025–2026 sicherzustellen.

Vorbereitungsschritte

1. Bestandsaufnahme der aktuellen Zertifikate und deren Nutzung

• Überprüfen Sie alle vorhandenen SSL/TLS-Zertifikate, um festzustellen, welche die Client-Authentifizierungs-EKU enthalten .
• Bestimmen Sie, welche Anwendungen diese Zertifikate für die Client-Authentifizierung verwenden (z. B. gegenseitiges TLS, Geräteauthentifizierung).
• Prüfen Sie, ob und wie diese Anwendungen, die sowohl ein öffentlich vertrauenswürdiges ServerAuth- als auch ein ClientAuth-Zertifikat benötigen, die Konfiguration separater ClientAuth- und ServerAuth-Zertifikate (und Schlüssel) tatsächlich unterstützen. Falls nicht, wenden Sie sich an den Anwendungsanbieter, wenn diese Funktion unterstützt wird.

2. Planen Sie die Zertifikatssegmentierung

• Trennen Sie die Client- und Serverauthentifizierungsrollen, indem Sie für jeden Zweck dedizierte Zertifikate verwenden.
• Besorgen Sie sich Client-Zertifikate mit der ClientAuth- EKU ausschließlich zur Client-Authentifizierung und Server-Zertifikate nur mit der ServerAuth -EKU.

3. Aktualisieren Sie Systeme und Anwendungen

• Ändern Sie die Client- und Serversoftware, um unterschiedliche Zertifikate für gegenseitiges TLS und andere Client-Authentifizierungsmethoden zu unterstützen.
• Stellen Sie sicher, dass Anwendungen EKU-Werte korrekt validieren, um die Annahme unzulässiger Zertifikate zu vermeiden.

4. Passen Sie die Zertifikatsverwaltungsprozesse an

• Aktualisieren Sie interne Richtlinien und Dokumentation, um die neuen Einschränkungen der EKU-Nutzung zu berücksichtigen.
• Koordinieren Sie die Zertifikatsausstellung ohne ClientAuth EKU in Serverzertifikaten nach Ablauf der Fristen mit den Zertifizierungsstellen.

5. Testen und Validieren

• Führen Sie vor der Produktionseinführung Tests mit geplanten Zertifikatsänderungen in Staging- oder Entwicklungsumgebungen durch.
• Überprüfen Sie, ob alle Authentifizierungsabläufe, einschließlich gegenseitigem TLS, mit neuen Zertifikatkonfigurationen ordnungsgemäß funktionieren.

6. Änderungen kommunizieren

• Informieren Sie die Beteiligten, einschließlich IT, Sicherheitsteams und Anwendungseigentümer, über die Auswirkungen der EKU-Veralterung.
• Bieten Sie Schulungen oder Anleitungen zur Handhabung neuer Zertifikate und zu PKI-Praktiken an.

 

Übersichtstabelle

Aktion	Beschreibung
Zertifikatsbestand	Identifizieren von Zertifikaten mit ClientAuth EKU
Verwenden Sie dedizierte Zertifikate	Separate Client- und Serverrollen mit relevanten EKUs
System-/Anwendungsupdates	Unterstützen und Erzwingen der EKU-spezifischen Zertifikatsverwendung
Richtlinien-/Prozessanpassung	Berücksichtigen Sie die Abwertung von EKU in den Richtlinien zur Ausstellung/Verlängerung.
Testen und Validieren	Bestätigen Sie die Funktionalität mit neuen Zertifikatseinstellungen
Stakeholder-Kommunikation	Informieren Sie Teams über EKU-Änderungen und -Compliance

 

Durch Befolgen dieses Fahrplans können Unternehmen Betriebsunterbrechungen minimieren und während der Umstellung auf die Client Authentication EKU eine starke PKI-Sicherheitslage aufrechterhalten.

 

Spezifische Informationen für KeyTalk-Kunden

Die Zertifikats- und Schlüsselverwaltungslösung von KeyTalk ermöglicht die automatische Erneuerung von Zertifikaten (und privaten Schlüsseln) und bietet die Möglichkeit, diese Zertifikate zusätzlich automatisch an Ihren Zielendpunkt für eine Zielanwendung weiterzuleiten, zu installieren und zu konfigurieren.

KeyTalk-Kunden, die öffentlich vertrauenswürdige ClientAuth-Zertifikate benötigen, wird Folgendes empfohlen:

1. Erstellen Sie eine neue dedizierte Zertifikatsvorlage für die Anforderung öffentlich vertrauenswürdiger ClientAuth-Zertifikate. Am einfachsten ist es, Ihre vorhandene Mehrzweck-Zertifikatsvorlage zu kopieren und das Produkt in ein ClientAuth-Zertifikat für die entsprechende öffentliche Zertifizierungsstelle umzuwandeln. Vergessen Sie nicht, Ihre neue Zertifikatsvorlage mit der internen Datenbankregistrierungsstelle zu verknüpfen.
2. Definieren Sie die FQDNs für die Anwendungen, die ClientAuth-Zertifikate benötigen, entweder manuell als KeyTalk SEATs oder lassen Sie diese bei authentifizierten neuen Zertifikatsanforderungen automatisch erstellen.
3. Testen Sie, ob die Registrierung erfolgreich war und Ihr KeyTalk CKMS den richtigen Zertifikatstyp erhalten hat.
4. Aktivieren Sie ACME, wenn dies für Ihre neue ClientAuth-Zertifikatvorlage zutreffend ist, und notieren Sie sich die eindeutige KeyTalk ACME-Server-URL
5. Konfigurieren Sie gegebenenfalls Ihre vorhandenen ACME-Agenten, die auf den Endpunkten ausgeführt werden, auf denen die Anwendungen gehostet werden, die das zusätzliche ClientAuth-Zertifikat benötigen, um ein zusätzliches Zertifikat von der neu aktivierten ACME-URL anzufordern
6. Konfigurieren Sie gegebenenfalls Ihre vorhandenen KeyTalk Enterprise-Agenten, die auf den Endpunkten ausgeführt werden, auf denen die Anwendungen gehostet werden, die das zusätzliche ClientAuth-Zertifikat benötigen, um ein zusätzliches Zertifikat aus der neu aktivierten Zertifikatvorlage anzufordern, UND aktualisieren Sie gegebenenfalls die verbundenen Powershell- oder Bash-Skripte, um das erhaltene ClientAuth-Zertifikat ordnungsgemäß auf die Zielanwendung anzuwenden
7. Testen Sie, ob die automatisierten ClientAuth-Zertifikate korrekt abgerufen und korrekt auf Ihre Zielanwendung(en) angewendet werden.

 

Haben Sie Fragen zu diesem Artikel oder dazu, wie Ihnen KeyTalk CKMS bei der Verwaltung und Automatisierung von digitalen Zertifikaten hilft? Unser Support-Team steht Ihnen rund um die Uhr zur Verfügung, um Ihnen bei der Implementierung einer vollständig automatisierten PKI-Architektur per E-Mail oder über unsere Kontaktseite zu helfen und Sie zu beraten.

Das KeyTalk-Team