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
En ce qui concerne les certificats TLS/SSL publics, c'est-à-dire ceux utilisés sur Internet, SwissSign se conformera bien entendu à cette exigence. Suite à la prolongation du délai accordée par Google, nous avons revu notre calendrier. Nous mettrons en œuvre ce changement au début de l'année 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.
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. Solution alternative avec S/MIME
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.
