Hauptbereich
Client Authentication in SSL/TLS-Zertifikaten ab 2026 nicht mehr unterstützt – Was Sie jetzt tun müssen
Per Juni 2026 darf der Verwendungszweck "Client-Authentisierung" nicht mehr in öffentlichen SSL/TLS-Zertifikaten eingetragen werden, andernfalls werden sie nicht mehr von Google Chrome als vertrauenswürdig eingestuft. Prüfen Sie rechtzeitig, ob und in welchem Umfang Sie Ihre SSL/TLS-Zertifikate auf diese Weise nutzen und welche Alternativen für Ihre Verschlüsselung zur Verfügung stehen – Hintergrund und Empfehlungen von SwissSign.
Das Google Chrome-Team hat beschlossen, den Verwendungszweck "Client Authentication" in der Extended Key Usage (EKU) von SSL/TLS-Server-Zertifikaten per 15. Juni 2026 nicht mehr zu akzeptieren (siehe Google Chrome Root Program Policy) – nur noch "Server Authentication" ist zukünftig erlaubt. Google Chrome will damit eine saubere Trennung der Anwendungen für Server- und für Client-Authentisierung durchsetzen.
Umsetzung für SwissSign-Zertifikate im 2. Quartal 2026
Für öffentliche, also zur Verwendung im Internet genutzte TLS-Zertifikate, wird SwissSign diese Vorgabe im 2. Quartal 2026 umsetzen. Wir informieren über den konkreten Zeitplan in unserem Blog und per RSS-Feed " Service Status". Diese Zertifikate können anschliessend nur noch für die Server-Seite einer TLS-Verbindung genutzt werden.
Wer nicht betroffen ist
Wahrscheinlich nutzten Sie als SwissSign-Kunde Ihre von SwissSign bezogenen SSL/TLS-Zertifikate nur für den vorgesehenen Zweck, d.h. für die TLS-Server-Authentisierung im Internet. In diesem Fall betrifft die Änderung Sie nicht, alles wird weiterhin wie gewohnt ablaufen und funktionieren.
Unsere Empfehlung: Scannen, Inventarisieren, Automatisieren und Ersetzen
1. Bestandsaufnahme Ihrer Zertifikate
Sollten Sie unsicher sein, ob in Ihrem Unternehmen öffentliche SSL/TLS-Server-Zertifikate als Client-Zertifikate eingesetzt werden, empfehlen wir Ihnen, frühzeitig eine Bestandsaufnahme und Analyse durchzuführen.
Angesichts der anstehenden Verkürzung der Laufzeiten öffentlicher SSL/TLS-Zertifikate und Domain-Validierungen zu diesem Zweck, sollten Organisationen ohnehin so bald wie möglich ihr Zertifikatsmanagement unter die Lupe nehmen, denn bisherige Prozesse werden unter den neuen Bedingungen nicht mehr so laufen können wie heute. Im deutschsprachigen Raum managen 90% unserer Zertifikatskunden ihre Zertifikate bisher mindestens teilweise manuell und die meisten benötigen mehrere Stunden für das Ersetzen jedes einzelnen Zertifikats. Wenn dies künftig einmal alle zwei Monate anstatt einmal im Jahr gemacht werden muss, braucht es einen genaueren Überblick und mehr Automatisierung – und zu diesem Zweck ein Certificate-Lifecycle-Management-Lösung.
2. Betroffene öffentliche Zertifikate durch private Zertifikate ersetzen
Sofern Ihre Analyse ergibt, dass einige der Zertifikate für die Client-Authentisierung eingesetzt werden, empfehlen wir, für diese private Zertifikate einzusetzen, die nicht für die Verwendung im Internet gedacht sind. Solche privaten Zertifikate können als Teil einer dedizierten, von SwissSign bereitgestellten privaten Managed PKI ausgestellt werden.
3. Workaround mit S/MIME
Alternativ können auch Zertifikate des Produkttyps "Pro S/MIME E-Mail ID Gold with Auth." für besagte Client-Authentisierung zum Einsatz kommen. Dieses Produkt steht in jeder Managed PKI von SwissSign ab Stufe OV (Organization Validation) zur Verfügung.
Benötigen Sie Unterstützung bei der Umstellung auf die neuen Zertifikate?
Möchten Sie verstehen, wie Sie Ihr Zertifikatsmanagement für die kommenden Jahre neu aufstellen können?
Call mit unseren Experten vereinbarenEKU und Client Authentication: Technischer Hintergrund
"mutual TLS": Wenn die Authentisierung des Clients Bestandteil einer SSL/TLS-Verbindung ist
Eine SSL/TLS-Verbindung wird von einem Client (zum Beispiel einem Browser) zu einem Server (zum Beispiel einem Webserver) aufgebaut. Dabei wird für den Verbindungsaufbau ein "Handshake" durchgeführt. SSL/TLS hat zum Zweck:
-
Verschlüsselung der Verbindung
-
Authentisierung des Servers
-
Optional: Authentisierung des Clients
Für die Authentisierung des Servers kommen die erwähnten Server-Zertifikate zum Einsatz. Falls Client-Authentisierung erfolgt und Client-Zertifikate verwendet werden, ist von "mutual TLS" die Rede.
Der TLS-Verbindungsaufbau, der "Handshake", ist nachfolgend für die beiden TLS-Versionen 1.2 und 1.3 graphisch dargestellt.

Weitere Erläuterungen zur neusten TLS-Version 1.3 und dessen Vorteile finden Sie im Blog-Beitrag "Was ist TLS 1.3 – und was sind die Vorteile gegenüber der Version TLS 1.2?"
Extended Key Usage: Server- und Client-Authentifizierung
In den Public-Key-Zertifikaten wird die vorgesehene Verwendung in einem speziellen Zertifikatsfeld (einer "Zertifikats-Erweiterung") eingetragen. Es handelt sich um die Erweiterung namens "Extended Key Usage" (EKU). Bislang wurde diese in öffentlichen SSL/TLS-Zertifikaten wie folgt befüllt:
-
TLS-WWW-Serverauthentifizierung (OID: 1.3.6.1.5.5.7.3.1)
-
TLS-WWW-Client-Authentifizierung (OID: 1.3.6.1.5.5.7.3.2)
Der erste Eintrag (TLS-WWW-Serverauthentifizierung) wird weiterhin enthalten sein, der zweite (TLS-WWW-Client-Authentifizierung) wird wegfallen.