Hauptbereich
Update: Client Authentication in TLS/SSL-Zertifikaten ab 2027 nicht mehr unterstützt – Was Sie jetzt tun müssen
Per März 2027 darf der Verwendungszweck "Client-Authentisierung" nicht mehr in öffentlichen TLS/SSL-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 TLS/SSL-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 TLS/SSL-Server-Zertifikaten nicht mehr zu akzeptieren (siehe Google Chrome Root Program Policy, v1.8) – 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.
Zunächst hatte Google eine Deadline Mitte Juni 2026 kommuniziert. Diese wurde nun verschoben. Die neueste Policy sieht zwei aufeinanderfolgende Stichtage vor:
-
15. Juni 2026: Neue Zwischen-Zertifizierungsstellen (Intermediate/Sub-CAs), die nach diesem Datum im CCADB offengelegt werden, dürfen ausschliesslich noch die EKU id-kp-serverAuth enthalten.
-
15. März 2027: Alle neu ausgestellten öffentlichen TLS-Subscriber-Zertifikate (d.h. die Zertifikate, die Sie als Kunde beziehen) dürfen ausschliesslich noch die EKU id-kp-serverAuth enthalten.
Umsetzung für SwissSign-Zertifikate im Q1 2027
Für öffentliche, also zur Verwendung im Internet genutzte TLS-Zertifikate, wird SwissSign diese Vorgabe selbstverständlich umsetzen. Nach der Fristenverlängerung von Google haben wir unseren Zeitplan überarbeitet und werden die Änderungen anfangs 2027 umsetzen.
Wir informieren über das genaue Datum so bald wie möglich hier 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 TLS/SSL-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 TLS/SSL-Server-Zertifikate als Client-Zertifikate eingesetzt werden, empfehlen wir Ihnen, frühzeitig eine Bestandsaufnahme und Analyse durchzuführen.
Sollten Sie unsicher sein, ob in Ihrem Unternehmen öffentliche TLS/SSL-Server-Zertifikate als Client-Zertifikate eingesetzt werden, empfehlen wir Ihnen, frühzeitig eine Bestandsaufnahme durchzuführen. Im Zuge der Kürzung der Laufzeiten von TLS/SSL-Zertifikaten auf 47 Tage raten wir ohnehin dringend dazu (Details in unserem Blogbeitrag).
Im deutschsprachigen Raum managen 90% der Zertifikatskunden ihre Zertifikate mindestens teilweise manuell und benötigen mehrere Stunden für das Ersetzen jedes einzelnen Zertifikats. Wenn dies künftig alle zwei Monate statt einmal im Jahr erfolgen muss, sind manuelle Prozesse nicht mehr tragbar. Eine Certificate Lifecycle Management-Lösung (CLM) automatisiert Inventarisierung, Erneuerung und Verteilung vollständig – und hilft Ihnen, beide Herausforderungen gleichzeitig zu meistern.
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 Sponsor Validated S/MIME-Zertifikate können 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 TLS/SSL-Verbindung ist
Eine TLS/SSL-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. TLS/SSL 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 TLS/SSL-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.
