Main section
Client Authentication in SSL/TLS Certificates will no longer be supported by mid-2026 - What you need to do now
As of June 2026, 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) - only "Server Authentication" will be allowed in the future. Google Chrome aims to enforce a clean separation of applications for server and client authentication.
Implementation of SwissSign certificates in the second quarter of 2026
For public SSL/TLS certificates, which are used on the Internet, SwissSign will implement this requirement in the second quarter of 2026. We will inform you about the concrete schedule 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.
With the upcoming reduction in the lifetimes of public SSL/TLS certificates and domain validations, organisations should in any case review their certificate management as soon as possible, as the processes they have used up to now will not work as well under the new conditions. In Germany and Switzerland, 90% of our certificate customers manage at least a part of their certificates manually and most of them need several hours to replace each certificate. If this has to be done every two months instead of once a year in the future, a more precise overview and more automation will be needed – and for this purpose, a certificate lifecycle management solution.
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, certificates of the product type "Pro S/MIME Email ID Gold with Auth." can also be used for the said 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.
