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.

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.

Two developments make this urgently necessary:

• June 2026: Client authentication will be removed from public TLS certificates

• From March 2026: Terms will be gradually reduced to 47 days (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, 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?

EKU 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.

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.