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.
Questions fréquemment posées (FAQ)
À partir du 15 mars 2027, les certificats TLS/SSL publics nouvellement émis devront contenir exclusivement Server Authentication. L’usage Client Authentication ne sera alors plus autorisé dans les nouveaux certificats TLS/SSL publics.
Google Chrome souhaite établir une distinction claire entre les certificats destinés à l’authentification des serveurs et ceux destinés à l’authentification des clients:
-
Server Authentication: authentification de sites web et de services accessibles au public
-
Client Authentication: authentification d’utilisateurs, d’appareils ou de systèmes auprès de serveurs
À l’avenir, les certificats TLS/SSL publics devront être utilisés exclusivement côté serveur d’une connexion TLS.
SwissSign introduit de nouveaux profils de certificats contenant exclusivement l’usage Server Authentication (serverAuth). Les nouveaux profils de certificats MPKI devraient être disponibles fin septembre 2026. Les profils actuels contenant clientAuth et serverAuth devraient être remplacés fin janvier 2027.
Les dates suivantes sont importantes pour la transition:
-
28 septembre 2026: Les nouveaux profils de certificats MPKI contenant exclusivement Server Authentication seront disponibles.
-
Janvier 2027: Les profils de certificats actuels contenant clientAuth et serverAuth seront remplacés.
-
15 mars 2027: Les certificats TLS publics d’entité finale nouvellement émis devront contenir exclusivement Server Authentication.
Si vous utilisez les certificats TLS/SSL obtenus auprès de SwissSign exclusivement pour l’authentification de serveurs TLS sur Internet, vous n’êtes pas concerné par ce changement. Tout continuera à fonctionner comme auparavant.
Vous pourriez être concerné si vous utilisez également des certificats de serveur TLS/SSL publics pour l’authentification client, par exemple pour:
- Mutual TLS (mTLS)
- l’authentification client entre applications
- l’authentification d’appareils
- l’authentification d’utilisateurs
- l’authentification machine à machine
Effectuez suffisamment tôt un inventaire et une analyse de vos certificats. Vérifiez notamment:
- Quels certificats TLS/SSL publics sont actuellement utilisés.
- Quels certificats sont utilisés pour l’authentification client.
- Quels systèmes utilisent Mutual TLS (mTLS).
- Quelles applications nécessitent des certificats clients.
Commencez cette vérification bien avant le 15 mars 2027.
-
Après le remplacement des profils de certificats SwissSign actuels, il ne sera plus possible d’émettre de nouveaux certificats TLS/SSL publics avec Client Authentication. Les certificats déjà émis avec Client Authentication resteront valables jusqu’à leur expiration.
-
Lors du renouvellement de ces certificats, les nouveaux certificats TLS/SSL publics ne contiendront plus que Server Authentication. Les applications qui nécessitent toujours une authentification client devront donc être migrées suffisamment tôt vers une solution appropriée.
SwissSign recommande de:
-
Réaliser suffisamment tôt un inventaire et une analyse de vos certificats.
-
Identifier les certificats TLS/SSL publics utilisés pour l’authentification client.
-
Remplacer ces certificats par des certificats privés ou par une solution S/MIME appropriée.
-
Automatiser l’inventaire, le renouvellement et la distribution à l’aide d’une solution de Certificate Lifecycle Management (CLM).
-
Migrer suffisamment tôt vers les nouveaux profils de certificats MPKI avec Server Authentication.
Pour l’authentification client, SwissSign recommande des certificats privés qui ne sont pas destinés à une utilisation sur Internet. Ils peuvent être émis dans le cadre d’une Managed PKI privée dédiée de SwissSign.
Oui. Les certificats S/MIME Sponsor Validated peuvent également être utilisés pour l’authentification client. Ils sont disponibles dans chaque Managed PKI de SwissSign à partir du niveau OV (Organization Validation).
Si vous gérez un grand nombre de certificats, le CLM peut notamment automatiser les processus suivants:
-
Inventaire
-
Renouvellement
-
Distribution
-
Surveillance du cycle de vie des certificats
-
Remplacement des certificats concernés
Cela réduit les tâches manuelles et facilite à la fois la gestion de durées de validité plus courtes et la migration vers de nouveaux profils de certificats.
