Section générale
Mise à jour: l’authentification client dans les certificats TLS/SSL ne sera plus prise en charge à partir de 2027. Voici ce que vous devez faire dès maintenant.
À compter de mars 2027, la finalité d’utilisation «Client Authentication» ne pourra plus être mentionnée dans les certificats TLS/SSL publics, faute de quoi ils ne seront plus considérés comme fiables par Google Chrome. Vérifiez en temps utile si et dans quelle mesure vous utilisez vos certificats TLS/SSL de cette manière. Découvrez les alternatives à votre disposition pour votre cryptage. Contexte et recommandations de SwissSign.
L’équipe Google Chrome a décidé de ne plus accepter la finalité d’utilisation «Client Authentication» dans l’Extended Key Usage (EKU) des certificats de serveurs TLS/SSL (voir Google Chrome Root Program Policy, v1.8) – seule l’utilisation «Server Authentication» sera autorisée à l’avenir. Google Chrome souhaite ainsi imposer une séparation nette entre les applications destinées à l’authentification serveur et celles destinées à l’authentification client.
Au départ, Google avait annoncé une date butoir fixée à la mi-juin 2026. Celle-ci a désormais été reportée. La nouvelle regulation prévoit deux dates butoirs consécutives:
-
15 juin 2026: les nouvelles autorités de certification intermédiaires (Intermediate/Sub-CAs) publiées dans la CCADB après cette date ne pourront plus contenir que l'EKU id-kp-serverAuth.
-
15 mars 2027: tous les nouveaux certificats TLS d'abonné publics (c'est-à-dire les certificats que vous obtenez en tant que client) ne pourront plus contenir que l'EKU id-kp-serverAuth.
Mise en œuvre pour les certificats SwissSign en Q1-2027
Pour les certificats TLS publics, c’est-à-dire utilisés sur Internet, SwissSign mettra bien entendu en œuvre cette exigence. À la suite du report du délai par Google, nous avons revu notre calendrier. Les nouveaux profils de certificats, qui ne contiendront à l’avenir plus que l’usage prévu «Server Authentication», devraient être disponibles fin septembre 2026. Les profils de certificats actuels avec clientAuth et serverAuth devraient être remplacés fin janvier 2027.
Nous vous communiquerons la date précise sur notre blog et via le flux RSS «Service Status». Ces certificats ne pourront ensuite plus être utilisés que pour le côté serveur d’une connexion TLS/SSL.
Qui n’est pas concerné
En tant que client SwissSign, vous n’avez probablement utilisé vos certificats TLS/SSL obtenus auprès de SwissSign qu’aux fins prévues, c’est-à-dire pour l’authentification serveur TLS/SSL sur Internet. Dans ce cas, le changement ne vous concerne pas, tout continuera de fonctionner comme à l’accoutumée.
Qu’est-ce qui change concrètement?
-
Les nouvelles politiques ICA et leaf ne contiendront à l’avenir plus que «Server Authentication».
-
Les nouveaux profils de certificats MPKI devraient être disponibles à partir de fin septembre 2026.
-
Les politiques actuelles avec clientAuth et serverAuth seront remplacées fin janvier 2027.
-
Les nouveaux certificats TLS/SSL publiquement approuvés ne pourront ensuite plus être utilisés pour l’authentification client.
Nouveaux profils de certificats à partir de septembre 2026
L’aperçu ci-dessous présente les profils de certificats MPKI actuels ainsi que leurs nouvelles désignations. Les nouveaux profils incluront désormais exclusivement l’usage Server Authentication (serverAuth).
Désignation actuelle du produit |
Nouvelle désignation du produit |
|---|---|
| SwissSign DV SSL Silver Single-Domain | SwissSign TLS DV Single-Domain |
| SwissSign DV SSL Silver Wildcard |
SwissSign TLS DV Wildcard |
| SwissSign DV SSL Silver Multi-Domain | SwissSign TLS DV Multi-Domain |
|
SwissSign OV SSL Gold Single-Domain |
SwissSign TLS OV Single-Domain |
| SwissSign OV SSL Gold Multi-Domain |
SwissSign TLS OV Multi-Domain |
|
SwissSign OV SSL Gold Multi-Domain Wildcard |
SwissSign TLS OV Multi-Domain Wildcard |
|
SwissSign OV SSL Gold Wildcard |
SwissSign TLS OV Wildcard |
|
SwissSign EV SSL Gold Single-Domain |
SwissSign TLS EV Single-Domain |
| SwissSign EV SSL Gold Multi-Domain |
SwissSign TLS EV Multi-Domain |
Nos recommandations: scanner, inventorier, automatiser et remplacer
1. État des lieux de vos certificats
Si vous ne savez pas si votre entreprise utilise des certificats serveur TLS/SSL publics comme certificats client, nous vous recommandons de procéder à temps à un état des lieux et à une analyse.
Si vous n'êtes pas certain que votre entreprise utilise des certificats TLS/SSL publics comme certificats clients, nous vous recommandons de procéder à un inventaire dès que possible. Dans le cadre de la réduction de la durée de validité des certificats TLS/SSL à 47 jours, nous vous recommandons vivement de le faire (plus de détails dans notre article de blog).
En Allemagne, Autriche et Suisse, 90% de nos clients gèrent leurs certificats au moins en partie manuellement et ont besoin de plusieurs heures pour remplacer chaque certificat. Si cette opération doit désormais être effectuée tous les deux mois au lieu d'une fois par an, les processus manuels ne seront plus viables. Une solution de gestion du cycle de vie des certificats (CLM) automatise entièrement l'inventaire, le renouvellement et la distribution, et vous aide à relever ces deux défis simultanément.
2. Remplacer les certificats publics concernés par des certificats privés
Si votre analyse révèle que certains certificats sont utilisés pour l’authentification client, nous vous recommandons d’utiliser des certificats privés qui ne sont pas destinés à être utilisés sur Internet. Ces certificats privés peuvent être émis dans le cadre d’une Managed PKI privée dédiée fournie par SwissSign.
3. Alternative: certificats S/MIME à des fins d’authentification
Vous pouvez également utiliser des certificats S/MIME de type «Sponsor Validated» pour cette authentification client. Ce produit est disponible dans toutes les Managed PKI de SwissSign à partir du niveau OV (Organization Validation).
Vous avez besoin d’aide pour le passage aux nouveaux certificats?
Vous souhaitez comprendre comment remanier votre gestion des certificats pour les années à venir?
Convenir d’un appel avec nos expertsEKU et authentification client: contexte technique
«mutual TLS»: quand l’authentification client fait partie intégrante d’une connexion TLS/SSL
Une connexion TLS/SSL est établie entre un client (p. ex. un navigateur) et un serveur (p. ex. un serveur web). Un «handshake» est alors effectué pour établir la connexion. Objectifs du protocole TLS/SSL:
-
Cryptage de la connexion
-
Authentification du serveur
-
En option: authentification du client
Les certificats serveur mentionnés sont utilisés pour l’authentification du serveur. Si l’authentification client a aussi lieu et que des certificats client sont utilisés, on parle de «mutual TLS».
L’établissement de la connexion TLS/SSL, le «handshake», est schématisé ci-dessous pour les deux versions TLS/SSL 1.2 et 1.3.
Vous trouverez d’autres explications sur la dernière version TLS 1.3 et ses avantages dans l’article de blog «Qu’est-ce que TLS 1.3 – et quels sont ses avantages par rapport à la version TLS 1.2?»
Extended Key Usage: authentification serveur et client
Dans les certificats à clé publique, l’utilisation prévue est indiquée dans un champ spécial du certificat (une «extension de certificat»). Il s’agit de l’extension appelée «Extended Key Usage» (EKU). Jusqu’à présent, celle-ci était remplie comme suit dans les certificats TLS/SSL publics:
-
Authentification serveur TLS/SSL-WWW (OID: 1.3.6.1.5.5.7.3.1)
-
Authentification client TLS/SSL-WWW (OID: 1.3.6.1.5.5.7.3.2)
La première entrée (authentification serveur TLS/SSL-WWW) sera toujours incluse, la seconde (authentification client TLS/SSL-WWW) sera supprimée.
