Section générale
L’authentification client dans les certificats SSL/TLS ne sera plus prise en charge à partir de mi-2026 – ce que vous devez faire dès maintenant
À compter de juin 2026, la finalité d’utilisation «authentification client» ne pourra plus être mentionnée dans les certificats SSL/TLS 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 SSL/TLS 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 SSL/TLS à compter du 15 juin 2026 (voir Google Chrome Root Program Policy) – 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.
Mise en œuvre pour les certificats SwissSign au 2e trimestre 2026
SwissSign mettra en œuvre cette exigence au 2e trimestre 2026 pour les certificats SSL/TLS publics, c’est-à-dire ceux utilisés sur Internet. Nous vous informerons du calendrier précis 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 SSL/TLS.
Qui n’est pas concerné
En tant que client SwissSign, vous n’avez probablement utilisé vos certificats SSL/TLS obtenus auprès de SwissSign qu’aux fins prévues, c’est-à-dire pour l’authentification serveur SSL/TLS sur Internet. Dans ce cas, le changement ne vous concerne pas, tout continuera de fonctionner comme à l’accoutumée.
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 SSL/TLS publics comme certificats client, nous vous recommandons de procéder à temps à un état des lieux et à une analyse.
Compte tenu de la réduction prochaine de la durée de validité des certificats SSL/TLS publics et des validations de domaine à cette fin, les organisations devront de toute façon examiner leur gestion des certificats dès que possible, car les processus actuels ne pourront plus fonctionner comme aujourd’hui dans les nouvelles conditions. En Suisse et en Allemagne, 90% de nos clients certifiés gèrent jusqu’à présent leurs certificats manuellement, au moins partiellement, et la plupart d’entre eux 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, il faudra disposer d’une vue d’ensemble plus précise et d’une plus grande automatisation. Pour cela, une solution de gestion du cycle de vie des certificats sera nécessaire.
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. Solution alternative avec S/MIME
Vous pouvez également utiliser des certificats de type «Pro S/MIME E-Mail ID Gold with Auth.» 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 SSL/TLS»: quand l’authentification client fait partie intégrante d’une connexion SSL/TLS
Une connexion SSL/TLS 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 SSL/TLS:
-
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 SSL/TLS».
L’établissement de la connexion SSL/TLS, le «handshake», est schématisé ci-dessous pour les deux versions SSL/TLS 1.2 et 1.3.
Vous trouverez d’autres explications sur la dernière version SSL/TLS 1.3 et ses avantages dans l’article de blog «Qu’est-ce que SSL/TLS 1.3 – et quels sont ses avantages par rapport à la version SSL/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 SSL/TLS publics:
-
Authentification serveur SSL/TLS-WWW (OID: 1.3.6.1.5.5.7.3.1)
-
Authentification client SSL/TLS-WWW (OID: 1.3.6.1.5.5.7.3.2)
La première entrée (authentification serveur SSL/TLS-WWW) sera toujours incluse, la seconde (authentification client SSL/TLS-WWW) sera supprimée.
