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 (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 ce qui concerne les certificats TLS 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 sommes en train de revoir notre calendrier et vous en informerons dès que possible 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.

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.

Si vous n'êtes pas certain que votre entreprise utilise des certificats SSL/TLS 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 SSL/TLS à 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 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?

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

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.