Implementation of SwissSign certificates in the first quarter of 2027

For public TLS certificates, i.e. certificates used on the internet, SwissSign will of course implement this requirement. Following Google’s deadline extension, we have revised our schedule. The new certificate profiles, which will in future contain only the intended usage “Server Authentication”, are expected to be available at the end of September 2026. The existing certificate profiles with clientAuth and serverAuth are expected to be replaced at the end of January 2027.

We will communicate the exact date 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.

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. Alternative: S/MIME certificates for authentication purposes

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?

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.

Frequently asked questions (FAQ)