Entfernung der Client-Authentifizierungs-EKU aus TLS Server-Zertifikate – Das müssen Sie wissen

Übersicht

Beginn September 15, 2025, SSL.com TLS Server Zertifikate wird ausgegeben ohne inklIng. die Client-Authentifizierung Erweiterung für erweiterte Schlüsselverwendung (EKU). Diese Übernehmen orientiert sich an der Richtlinie zum Root-Programm von Google Chrome. Hier, Wir erklären, was EKUs sind, warum diese Änderung stattfindet, wie sie impact Serverumgebungen und welche Maßnahmen Sie möglicherweise ergreifen müssen. Wir haben auch die eine FAQ und technische Anleitungen für verschiedene Szenarien. 

Wichtiges Update: Ab dem 15. März 2027 unterstützt Google Chrome keine Endbenutzerzertifikate mehr, die die ClientAuth-EKU enthalten. Diese Änderung betrifft ausschließlich Chrome. Andere wichtige Stammzertifikatspeicher oder Google-Dienste wie Gmail und Google Trust Services sind davon nicht betroffen.  

Wenn Sie ClientAuth in Chrome-basierten Umgebungen verwenden, empfehlen wir Ihnen, sich mit unserem Team in Verbindung zu setzen, damit wir gemeinsam die beste Lösung für Ihre Organisation finden können.

Was sind erweiterte Schlüsselverwendungen (EKUs)? 

Erweiterte Schlüsselverwendung (EKU), ist eine Zertifikatserweiterung, die die beabsichtigte Funktion eines öffentlichen Schlüssels innerhalb eines digitalen Zertifikats definiert. Sie legt einen strukturierten Satz zulässiger Anwendungen fest und stellt sicher, dass der Schlüssel nur für bestimmte kryptografische Operationen verwendet wird. Diese Funktionalität wird geregelt durch Objektkennungen (OIDs)– eindeutige numerische Kennungen, die jede zulässige Verwendung kategorisieren, z. B. Codesignatur, Serverauthentifizierung, Clientauthentifizierung oder sichere E-Mail. Wenn die Authentifizierung zertifikatsbasiert ist, prüft die verifizierende Entität das Zertifikat, um den Objektbezeichner (OID) innerhalb der EKU zu identifizieren. Durch die Einbettung der EKU-Erweiterung wird ein Zertifizierungsstelle (CA) beschränkt den Umfang des Zertifikats auf vordefinierte Rollen, wobei jeder angegebene Zweck explizit einer OID zugeordnet ist. 

Beispielsweise: 

• TLS Webserver-Authentifizierung – Gibt an, dass das Zertifikat zur Authentifizierung eines Servers (z. B. einer HTTPS-Website) verwendet werden kann. Die OID, die der Serverauthentifizierung entspricht, ist 1.3.6.1.5.5.7.3.1 

• TLS Web-Client-Authentifizierung – Gibt an, dass das Zertifikat von einem Client zur Authentifizierung gegenüber einem Server verwendet werden kann (z. B. ein Client-Zertifikat für die gegenseitige TLS). Die der Client-Authentifizierung zugewiesene OID ist 1.3.6.1.5.5.7.3.2 

Browser und Server benötigen lediglich die serverAuth EKU zu etablieren eine sichere Verbindung für HTTPS, aber historisch viele TLS Server-Zertifikate umfassten sowohl die serverAuth und clientAuth EKUs.  Im Folgenden ist ein Beispiel für ein solches Zertifikat:

WAS IST ALLES Ereignis? 

Ab September 15, 2025, SSL.com wird Problem TLS Zertifikate, die nur die serverAuth EKU (und kein Frontalunterricht. clientAuth) für Server-Zertifikate. Anders ausgedrückt: neue SSL/TLS Zertifikate für Ihre Website oder Ihren Server dienen ausdrücklich nur der „Serverauthentifizierung“. 

Warum entfernen Sie die clientAuth EKU von Serverzertifikaten? 

Für dieses Mandat gibt es mehrere Gründe: 

• Sicherheit und Umfang: Öffentliche TLS Zertifikate sind soll nur Server authentifizieren im Web. Die Entfernung sorgt für eine klare Trennung zwischen Server- und Client-Funktionalität. Die ClientAuth EKU wird zur Authentifizierung von Maschinen und Benutzern mit Mutual TLS (mTLS) und andere Authentifizierungsszenarien. 

• Fehlkonfigurationen vermeiden: Einige Systeme vertrauen möglicherweise für Zertifikat einer öffentlichen Zertifizierungsstelle zur Client-Authentifizierung, wenn die EKU vorhanden ist, was ein Sicherheitsrisiko darstellen könnte. 

• Browseranforderungen: Die gängigen Browser erfordern oder überprüfen die ClientAuth-EKU im Zertifikat einer Website nicht.  

• Einfach PKI Die Architektur: Durch die Trennung der Nutzungen können CAs unterschiedliche Zertifikatshierarchien für Server verwalten TLS im Vergleich zu anderen Zwecken. 

Branchenkonformität 

Diese Richtlinienänderung ist zur Zeit Sein schrittweise eingeführt by der Google Chrome Root-Programm.  

Auswirkungen auf Serverumgebungen 

Für die überwiegende Mehrheit der Serverbereitstellungen wird diese Änderung geringe Auswirkung or keine Auswirkung. Folgendes erwartet Sie: 

• Standard-Webserver (HTTPS): Keine Auswirkungen. Die aktualisierten Zertifikate funktionieren weiterhin normal. 

• Vorhandene Zertifikate: Jedes ausgestellte Zertifikat bevor Die Sperre bleibt bis zu ihrem Ablauf aktiv. 

• gegenseitig TLS (mTLS) und Client-Zertifikatsszenarien: Wenn Sie ein TLS Serverzertifikat für Client-Authentifizierungbenötigen Sie ein separates Zertifikat mit der clientAuth-EKU aus einer anderen Quelle.  

• Unternehmenssysteme, die beide EKUs erfordern: Einige Legacy- oder Unternehmenssysteme erwarten beide EKUs. Sie sollten überprüfen, ob Updates erforderlich sind, um die neuen Regeln einzuhalten. 

• Zertifikate für API-Clients, IoT-Geräte usw.: Wenn Ihr Anwendungsfall auf clientAuth EKU basiert, benötigen Sie ein dediziertes Client-Authentifizierungszertifikat. SSL.com bietet Clientauthentifizierungszertifikate. 

Erforderliche Aktionen für Kunden 

1. Inventarisieren Sie Ihre Zertifikate: Identifizieren Sie alle TLS verwendete Zertifikate und prüfen Sie auf die ClientAuth-EKU. 
2. Identifizieren Sie alle Dual-Use-Fälle: Stellen Sie fest, ob eines Ihrer Systeme auf einem TLS Zertifikat zur Client-Authentifizierung. 
3. Plan zur Erneuerung/Neuausstellung des Zertifikats: Zukünftige Zertifikate werden standardmäßig ohne clientAuth EKU ausgestellt. 
4. Bei Bedarf frühzeitig neu ausstellen: Wenn Sie Ihre Zertifikate proaktiv aktualisieren möchten, können Sie diese vor Ablauf der Frist neu ausstellen. 
5. Besorgen Sie sich bei Bedarf Client-Authentifizierungszertifikate: Sichern Sie sich ein separates Zertifikat mit der clientAuth-EKU wenn benötigt. 
6. Dokumentation und Konfiguration aktualisieren: Ändern Sie alle automatisierten Zertifikatsanforderungsskripts oder Dokumentationen, die zuvor davon ausgegangen sind, dass beide EKUs vorhanden sind. 

FAQ (Häufig gestellte Fragen) 

F1. Was ist die EKU „Client-Authentifizierung“ und warum war sie in meinem Zertifikat? 

Die EKU „Client-Authentifizierung“ gibt an, dass ein Client ein Zertifikat zur Authentifizierung gegenüber einem Server verwenden kann. Einige Zertifizierungsstellen haben es in der Vergangenheit in TLS Zertifikate standardmäßig, aber es war nie für die normale Website-Sicherheit erforderlich. 

F2. Werden Browser mein Zertifikat ablehnen, wenn es nach dem 15. September über die ClientAuth-EKU verfügt? 

Nein, Browser werden nicht plötzlich damit beginnen, vorhandene Zertifikate mit der ClientAuth-EKU abzulehnen. Die Änderung betrifft die Neuausstellung. 

Q3. Mein aktueller TLS Im Zertifikat steht unter „Erweiterte Schlüsselverwendung“ „Client-Authentifizierung“. Ist es jetzt ungültig? 

Nein, es bleibt gültig. Sie müssen es nicht sofort ersetzen. Bei der Erneuerung enthält das neue Zertifikat lediglich nicht die clientAuth-EKU. 

F4. Wie kann ich überprüfen, ob ein Zertifikat über die ClientAuth-EKU verfügt? 

Sie können die Zertifikatsdetails mit OpenSSL, PowerShell oder GUI-Tools überprüfen, um zu prüfen, ob Erweiterte Schlüsselverwendung Erweiterung. 

F5. Unser System erfordert, dass das Serverzertifikat sowohl ServerAuth- als auch ClientAuth-EKUs enthält. Was sollten wir tun? 

Sie sollten Ihr System aktualisieren, sodass nur serverAuth für Server-Zertifikate. Wenn eine Client-Authentifizierung erforderlich ist, erhalten Sie ein separates Zertifikat mit dem clientAuth-EKU von SSL.com. 

F6. Kann ich mit nur Client Authentication EKU immer noch ein öffentlich vertrauenswürdiges Zertifikat erhalten? 

Einige CAs, wie SSL.com, bieten dedizierte Client-Authentifizierungszertifikate. Diese sind getrennt von TLS Zertifikate und werden normalerweise zur Unternehmensauthentifizierung verwendet. 

F7. Hat dies Auswirkungen auf andere EKUs oder Zertifikatstypen (Codesignatur, E-Mail usw.)? 

Nein, diese Änderung betrifft TLS Serverzertifikate. Für Code-Signierung und E-Mail-Zertifikate gelten eigene EKU-Anforderungen. 

F8. Wir verwenden auf unserer Website die Client-Zertifikat-Authentifizierung. Hat diese Änderung Auswirkungen darauf? 

Nein, auf Gegenseitigkeit TLS (mTLS) Authentifizierung funktioniert weiterhin. Stellen Sie jedoch sicher, dass die von den Benutzern vorgelegten Client-Zertifikate weiterhin die clientAuth-EKU Falls erforderlich. 

F9. Hängt dies mit der bevorstehenden Umstellung auf kürzere Zertifikatslaufzeiten (90-Tage-Zertifikate) zusammen? 

Nein, es handelt sich hierbei um separate Branchenänderungen, die jedoch beide auf eine Verbesserung der Sicherheit und der Zertifikatsverwaltungspraktiken abzielen. 

F10. Wo kann ich die offiziellen Anforderungen zu dieser Änderung sehen? 

Das Richtlinie zum Root-Programm von Google Chrome  bietet Richtlinien zum Verbot der clientAuth EKU in TLS Serverzertifikate. 

Zusammenfassung 

Das Entfernen der clientAuth EKU aus TLS Serverzertifikate sind eine branchenweite Richtlinienänderung, die die Sicherheit erhöht und Missbrauch verhindert. Für die meisten Benutzer wird es keine spürbaren Auswirkungen geben. Wenn Sie jedoch auf die clientAuth-EKU angewiesen sind, sollten Sie proaktiv Maßnahmen ergreifen, um den richtigen Zertifikatstyp für Ihre Anforderungen zu erhalten. 

Wenn Sie Fragen haben oder Hilfe benötigen, wenden Sie sich bitte an unser Support-Team unter support@ssl.com.