Main section
Client Authentication in SSL/TLS Certificates will no longer be supported by mid-2026 - What you need to do now
As of 15 March 2027, the use case "Client Authentication" may no longer be included in public SSL/TLS certificates, otherwise they would no longer be considered trustworthy by Google Chrome. Check in good time whether and to what extent you are using SSL/TLS certificates in this way, and what alternatives are available for your encryption - background and recommendations from SwissSign.
The Google Chrome team has decided to no longer accept the "Client Authentication" purpose in the Extended Key Usage (EKU) of SSL/TLS server certificates as of June 15, 2026 (see Google Chrome Root Program Policy, v1.8) - only "Server Authentication" will be allowed in the future. Google Chrome aims to enforce a clean separation of applications for server and client authentication.
Google had initially announced a deadline of mid-June 2026. This has now been postponed. The latest policy sets out two consecutive deadlines:
-
15 June 2026: New intermediate/sub-certification authorities (Intermediate/Sub-CAs) published in the CCADB after this date may only contain the EKU id-kp-serverAuth.
-
15 March 2027: All newly issued public TLS subscriber certificates (i.e. the certificates you obtain as a customer) must contain only the EKU id-kp-serverAuth.
Implementation of SwissSign certificates in the second quarter of 2026
SwissSign will, of course, comply with this requirement for public TLS certificates, i.e. those used on the internet. Following Google’s extension of the deadline, we are currently revising our schedule and will provide an update as soon as possible in our blog and via the RSS feed "Service Status". These certificates can then only be used for the server side of a TLS connection.
Those not affected
As a SwissSign customer, you probably only use your TLS certificates from SwissSign for the intended purpose, i.e. for SSL/TLS server authentication on the Internet. In this case, the change does not affect you, everything will continue to work as usual.
Our recommendation: Scan, inventory, automate and replace
1. Inventory of your certificates
If you are unsure whether public TLS server certificates are used as client certificates in your company, we recommend that you conduct an early inventory and analysis.
If you are unsure whether public SSL/TLS server certificates are used as client certificates in your company, we recommend that you take stock of the situation at an early stage. Following the reduction of SSL/TLS certificate validity periods to 47 days, we strongly recommend that you (details in our blog post).
In German-speaking countries, 90% of our certificate customers manage their certificates at least partially manually and need several hours to replace each individual certificate. If this has to be done every two months instead of once a year in future, manual processes will no longer be viable. A certificate lifecycle management (CLM) solution fully automates inventory, renewal and distribution – helping you to overcome both challenges at the same time.
2. Replace affected public certificates with private certificates
If your analysis shows that some of the certificates are used for client authentication, we recommend using private certificates for these that are not intended for use on the Internet. Such private certificates can be issued as part of a dedicated private managed PKI provided by SwissSign.
3. Workaround with S/MIME
Alternatively, you can also use Sponsor-Validated S/MIME certificates for client authentication. This product is available in every SwissSign Managed PKI from the OV (Organisation Validation) level.
Do you need help with the transition to the new certificates?
Would you like to understand how you can redesign your certificate management for the coming years?
Schedule a call with our expertsEKU and Client Authentication: Technical Background
"mutual TLS": If the client authentication is part of an SSL/TLS connection
An SSL/TLS connection is established from a client (for example, a browser) to a server (for example, a web server). A "handshake" is performed for the connection setup. SSL/TLS has the purpose of:
-
Connection encryption
-
Authentication of the server
-
Optional: Client authentication
For the authentication of the server, the mentioned server certificates are used. If client authentication is performed and client certificates are used, we speak of "mutual TLS".
The TLS connection setup, the "handshake," is graphically represented below for the two TLS versions 1.2 and 1.3.
For further explanations about the latest TLS version 1.3 and its benefits, please read the blog post "What is TLS 1.3 - and what are the benefits compared to TLS 1.2?"
Extended Key Usage: Server and client authentication
In public key certificates, the intended use is recorded in a special certificate field (a "certificate extension"). This is the extension called "Extended Key Usage" (EKU). Up to now, this has been pupulated in public SSL/TLS certificates as follows:
-
TLS WWW server authentication (OID: 1.3.6.1.5.5.7.3.1)
-
TLS WWW client authentication (OID: 1.3.6.1.5.5.7.3.2)
The first entry (TLS-WWW-Server Authentication) will continue to be included, the second (TLS-WWW-Client Authentication) will be removed.
