Résumé de la gestion
Cet article de blog aborde les changements à venir concernant la suppression de l’utilisation étendue de la clé d’authentification client (EKU) des certificats SSL/TLS de confiance publique , un changement motivé par des problèmes de sécurité et le besoin de rôles plus clairs dans les opérations cryptographiques.
À partir de septembre 2025, les principales autorités de certification (AC) commenceront à supprimer progressivement l’EKU d’authentification client de l’émission de certificats publics, avec une date limite finale pour cette extension d’ici la mi-2026.
Selon le forum CA/B, l’objectif principal de ces changements est de réduire les risques de sécurité associés aux certificats à double usage et d’imposer des directives plus strictes quant à leur utilisation. Les organisations s’appuyant sur l’authentification TLS ou client mutuelle devront adopter des certificats clients dédiés pour garantir la conformité et maintenir la sécurité de leurs opérations. Cet article de blog décrit les implications de ces changements, leurs avantages en matière de sécurité et les mesures à prendre pour préparer cette transition.
Introduction
La sécurité et la conformité sont des considérations primordiales pour les organisations utilisant des certificats cryptographiques pour l’authentification et la communication. La suppression de l’utilisation étendue de la clé d’authentification client (EKU) des certificats SSL va remodeler l’utilisation de ces certificats, notamment pour les scénarios TLS mutuels ( mTLS ). Cet article de blog offre un aperçu complet de l’utilisation étendue de la clé d’authentification client (EKU), de ses implications et du calendrier de sa mise en œuvre progressive . En comprenant ces changements à venir, les organisations peuvent prendre les mesures nécessaires pour garantir leur conformité et leur sécurité, tout en améliorant la clarté de leurs pratiques de gestion des certificats.
Qu’est-ce que l’utilisation étendue de la clé d’authentification client (EKU) ?
L’ EKU (Extended Key Usage) d’authentification client est une extension de certificat qui désigne un certificat numérique pour authentifier un client (tel qu’un utilisateur ou un appareil) auprès d’un serveur, couramment utilisé dans les scénarios TLS mutuels ( mTLS ).
Il s’agit d’une fonctionnalité ajoutée aux certificats numériques qui spécifie l’utilisation autorisée d’une clé publique. Elle crée une liste claire des utilisations autorisées, garantissant que la clé est réservée à certaines tâches cryptographiques. Les utilisations autorisées sont identifiées par des numéros uniques appelés identifiants d’objet (OID), qui catégorisent chaque objectif spécifique, comme la signature de code, l’authentification du serveur, l’authentification du client ou la messagerie sécurisée.
Lorsqu’un utilisateur vérifie un certificat, il consulte l’EKU pour trouver l’OID. En incluant l’extension EKU, une autorité de certification (CA) limite l’utilisation du certificat, en liant chaque fonction à un OID spécifique. Voici quelques exemples :
- Authentification du serveur Web TLS : le certificat permet de vérifier un serveur, comme pour un site web HTTPS. L’OID de l’authentification du serveur est 1.3.6.1.5.5.7.3.1 .
- Authentification client Web TLS : le certificat permet à un client de s’authentifier auprès d’un serveur, comme dans le cas d’un protocole TLS mutuel. L’OID de l’authentification client est 1.3.6.1.5.5.7.3.2 .
Normalement, les navigateurs et les serveurs n’ont besoin que de l’ EKU serverAuth pour établir une connexion HTTPS sécurisée. Cependant, de nombreux certificats de serveur TLS incluent historiquement les EKU serverAuth et clientAuth .
Utilisation d’EKU dans PKI
- Les EKU restreignent les rôles autorisés d’un certificat, tels que l’authentification du serveur, l’authentification du client, la signature de code ou la protection des e-mails.
- Lorsque l’authentification du client est requise (par exemple mTLS ), la présence de l’ EKU clientAuth signale à un système que le certificat peut être approuvé à cette fin.
- Historiquement, certains certificats TLS de serveur incluaient à la fois les EKU serverAuth et clientAuth , mais cette pratique est en cours d’abandon afin de réduire les risques de sécurité et de clarifier les rôles cryptographiques.
Changements dans l’industrie
- À partir de 2025-2026, les principales autorités de certification et les programmes racine du navigateur (tels que Google Chrome) exigeront la séparation des EKU d’authentification du serveur et du client, ce qui signifie que les certificats TLS publics ne devraient avoir que l’EKU serverAuth , et non clientAuth , pour éviter toute utilisation abusive et améliorer la sécurité.
- Les organisations nécessitant une authentification client auront désormais besoin de certificats clients dédiés avec l’ EKU clientAuth .
Impact de la suppression de l’authentification client EKU sur les certificats SSL
La suppression de l’ EKU d’authentification client des certificats SSL signifie que les futurs certificats de serveur public seront utilisés strictement pour l’authentification du serveur et non à des fins côté client comme le TLS mutuel ( mTLS ).
Impacts sur l’utilisation des certificats SSL
- Les certificats de serveur émis après mi-2025 n’incluront que l’ EKU serverAuth , empêchant toute utilisation ambiguë ou non sécurisée comme informations d’identification d’authentification client.
- Les certificats existants (émis avant les dates limites) restent valables jusqu’à leur expiration ; ils ne seront pas révoqués rétroactivement.
- Les serveurs Web HTTPS standard ne sont pas affectés, car les navigateurs (tels que Chrome et Firefox) vérifient uniquement l’authentification du serveur et ignorent l’ EKU clientAuth pour l’accès au site Web.
- Pour les environnements qui s’appuient sur mTLS ou sur l’authentification client/appareil avec des certificats SSL publics, un certificat d’authentification client distinct sera requis à l’avenir.
Avantages en matière de sécurité et de conformité
- Réduit les risques d’utilisation abusive et de double utilisation involontaire, améliorant la séparation entre l’Internet public et les infrastructures PKI internes.
- Aligne toutes les autorités de certification (CA) et tous les navigateurs selon des directives plus strictes qui prennent en charge les certificats sécurisés à usage unique.
Étapes pour les organisations
- Examinez les inventaires de certificats pour déterminer quels systèmes s’appuient sur des certificats à double usage /serveur pour l’authentification client.
- Mettre à jour les systèmes pour utiliser des certificats clients dédiés (avec clientAuth EKU) pour les connexions TLS mutuelles, l’authentification des appareils ou les connexions de serveur à serveur.
- Modifiez les processus/documentations de demande de certificat afin que les renouvellements futurs soient conformes aux nouvelles politiques et évitent les interruptions de service.
Tableau des effets
| Cas d’utilisation |
Changement après le retrait de l’EKU |
Action requise |
| Sites Web HTTPS |
Aucun impact ; le SSL standard continue |
Aucun |
| TLS mutuel ( mTLS ) |
Les certificats de serveur ne peuvent pas authentifier les clients |
Passer aux certificats clients dédiés |
| Systèmes hérités/d’entreprise |
Certificats à double usage rejetés ; incompatibilité possible |
Mettre à jour les systèmes, utiliser des certificats clients dédiés |
La suppression de l’authentification client EKU est une mesure de sécurité visant à garantir que les certificats SSL sont utilisés aux fins prévues, avec un impact minimal pour la plupart des utilisateurs, à l’exception de ceux qui s’appuient sur mTLS ou des environnements d’authentification mixtes.
Quand les autorités de certification cesseront-elles d’émettre des certificats avec l’authentification client EKU ?
Les autorités de certification (AC) commenceront à supprimer progressivement les certificats SSL/TLS avec l’ EKU d’authentification client à partir de septembre 2025, avec des dates limites finales à la mi-2026 selon l’AC.
Principaux points saillants de la chronologie de CA
- 15 septembre 2025 : la plupart des principales autorités de certification, y compris Sectigo et Trustico , cesseront d’inclure l’EKU d’authentification client par défaut. dans les nouveaux certificats SSL.
- 1er octobre 2025 : DigiCert cessera d’émettre des certificats TLS publics avec l’ EKU ClientAuth par défaut. Les demandes spéciales pourront être satisfaites jusqu’au 1er mai 2026, date à laquelle aucun certificat public ne pourra inclure l’EKU ClientAuth .
- 13-15 mai 2026 : Date limite finale pour l’ensemble du secteur ; toutes les principales autorités de certification (y compris Let’s Encrypt, Sectigo , DigiCert et Trustico ) supprimeront définitivement l’EKU d’authentification client de l’émission de nouveaux certificats SSL/TLS publics, y compris les renouvellements et les réémissions.
- 15 juin 2026 : le programme racine de Google Chrome ne fera confiance qu’aux certificats SSL publics avec serverAuth EKU, rejetant tout certificat avec ClientAuth EKU à partir de cette date.
Tableau récapitulatif
| Nom de l’AC |
Date d’arrêt par défaut |
Date limite stricte |
| Sectigo |
15 septembre 2025 |
15 mai 2026 |
| DigiCert |
1er octobre 2025 |
1er mai 2026 |
| Cryptons |
Début 2026 |
13 mai 2026 |
| Trustico |
15 septembre 2025 |
15 mai 2026 |
Après ces délais, aucun certificat SSL/TLS public nouveau ou renouvelé des principales autorités de certification ne contiendra l’EKU d’authentification client, marquant ainsi la transition à l’échelle de l’industrie.
Quels avantages en matière de sécurité découlent de la suppression de ClientAuth EKU ?
Selon le forum CA/B, la suppression de l’ EKU ClientAuth des certificats SSL publiquement approuvés apporte plusieurs avantages de sécurité clés en renforçant la spécificité de l’objectif du certificat et en réduisant les risques d’utilisation abusive ou de mauvaise configuration.
Séparation des rôles de confiance
- Les certificats de serveur public seront utilisés strictement pour l’authentification du serveur, et non pour l’authentification du client ou de l’appareil.
- Cela minimise le risque que les certificats soient réutilisés au-delà de leur fonction prévue, conformément au principe du moindre privilège.
Risque réduit de mauvaise configuration
- Certains systèmes acceptaient auparavant tout certificat avec un EKU ClientAuth pour l’authentification client, ce qui pouvait entraîner un accès non autorisé si un certificat de serveur public était approuvé par erreur.
- La restriction des EKU à leurs utilisations prévues rend l’architecture PKI plus claire et plus robuste pour la maintenance et les audits.
Amélioration de l’hygiène et de la conformité PKI
- L’application de hiérarchies de certificats distinctes pour les rôles serveur et client aligne les autorités de certification (CA) sur les exigences du navigateur et les normes PKI modernes.
- Réduit la complexité et la surface d’attaque des certificats polyvalents, facilitant ainsi la gestion et la sécurisation des déploiements PKI publics et privés.
Prévention des abus liés aux certificats polyvalents
- Les certificats à usage mixte (avec des EKU serverAuth et clientAuth ) peuvent être utilisés de manière abusive s’ils sont utilisés dans des schémas d’authentification non intentionnels, facilitant potentiellement le mouvement latéral ou l’escalade des privilèges.
- En exigeant des certificats distincts pour chaque objectif, les organisations peuvent mieux surveiller, auditer et contrôler les scénarios d’accès sensibles.
Tableau récapitulatif
| Prestation de sécurité |
Description |
| Séparation des rôles (moindre privilège) |
Empêche l’utilisation des certificats en dehors du champ d’application |
| Réduit le risque de mauvaise configuration |
Élimine le chevauchement accidentel des EKU client/serveur |
| Améliore l’architecture PKI |
Permet une séparation claire de l’infrastructure à clé publique (PKI) et l’application des politiques |
| Réduit la surface d’attaque |
Interdit l’accès involontaire via des certificats polyvalents |
En résumé, la suppression de ClientAuth EKU des certificats SSL du serveur renforce la sécurité en clarifiant l’utilisation des certificats, en appliquant la conformité et en réduisant le risque que les certificats publics soient utilisés à mauvais escient pour des scénarios d’authentification client sensibles.
Comment préparer vos systèmes à la chronologie d’obsolescence d’EKU ?
Pour préparer les systèmes à la chronologie d’obsolescence de l’EKU d’authentification client , les organisations doivent prendre des mesures proactives pour garantir la continuité des opérations sécurisées et la conformité d’ici les échéances 2025-2026.
Étapes de préparation
- Inventaire des certificats actuels et utilisation
- Auditez tous les certificats SSL/TLS existants pour identifier ceux qui incluent l’EKU d’authentification client .
- Déterminez quelles applications s’appuient sur ces certificats pour l’authentification client (par exemple, TLS mutuel, authentification de périphérique).
- Déterminez si et comment ces applications nécessitant un certificat public de confiance ServerAuth et ClientAuth prennent en charge la configuration de certificats (et de clés) ClientAuth et ServerAuth distincts. Dans le cas contraire, contactez le fournisseur de l’application pour savoir quand cette fonctionnalité sera prise en charge.
- Planifier la segmentation des certificats
- Séparez les rôles d’authentification client et d’authentification serveur en utilisant des certificats dédiés à chaque objectif.
- Obtenez des certificats clients avec ClientAuth EKU strictement pour l’authentification client et des certificats serveur avec ServerAuth EKU uniquement.
- Mettre à jour les systèmes et les applications
- Modifiez les logiciels client et serveur pour prendre en charge des certificats distincts pour TLS mutuel et d’autres méthodes d’authentification client.
- Assurez-vous que les applications valident correctement les valeurs EKU pour éviter d’accepter des certificats incorrects.
- Ajuster les processus de gestion des certificats
- Mettre à jour les politiques internes et la documentation pour refléter les nouvelles restrictions sur l’utilisation d’EKU.
- Coordonner avec les autorités de certification pour l’émission de certificats sans ClientAuth EKU dans les certificats de serveur après les délais.
- Tester et valider
- Effectuez des tests avec des modifications de certificat planifiées dans des environnements de préparation ou de développement avant le déploiement en production.
- Vérifiez que tous les flux d’authentification, y compris TLS mutuel, fonctionnent correctement avec les nouvelles configurations de certificat.
- Communiquer les changements
- Informez les parties prenantes, notamment les équipes informatiques, de sécurité et les propriétaires d’applications, de l’impact de l’obsolescence d’EKU.
- Fournir une formation ou des conseils sur la nouvelle gestion des certificats et les pratiques PKI.
Tableau récapitulatif
| Action |
Description |
| Inventaire des certificats |
Identifier les certificats avec ClientAuth EKU |
| Utiliser des certificats dédiés |
Séparez les rôles client et serveur avec les EKU pertinents |
| Mises à jour du système/des applications |
Soutenir et appliquer l’utilisation des certificats spécifiques à EKU |
| Ajustement des politiques/processus |
Refléter l’abandon d’EKU dans les politiques d’émission/renouvellement |
| Tests et validation |
Confirmer la fonctionnalité avec de nouvelles configurations de certificat |
| Communication avec les parties prenantes |
Sensibiliser les équipes aux changements et à la conformité d’EKU |
En suivant cette feuille de route, les organisations peuvent minimiser les perturbations opérationnelles et maintenir une posture de sécurité PKI solide tout au long de la transition vers l’obsolescence de l’EKU d’authentification client.
Informations spécifiques pour les clients KeyTalk
La solution de gestion des certificats et des clés de KeyTalk permet le renouvellement automatisé des certificats (et des clés privées) et fournit les moyens de relayer, d’installer et de configurer automatiquement ces certificats sur votre point de terminaison cible pour une application cible.
Il est conseillé aux clients de KeyTalk qui ont besoin de certificats ClientAuth publiquement approuvés de :
- Créez un nouveau modèle de certificat dédié pour la demande de certificats ClientAuth de confiance publique. Le plus simple est de copier votre modèle de certificat polyvalent existant et de le remplacer par un certificat ClientAuth pour l’autorité de certification publique concernée. N’oubliez pas de connecter votre nouveau modèle de certificat à l’autorité d’enregistrement de la base de données interne.
- Définissez manuellement les noms de domaine complets (FQDN) pour les applications nécessitant des certificats ClientAuth en tant que SEAT KeyTalk ou créez-les automatiquement lors de nouvelles demandes de certificat authentifiées.
- Vérifiez si l’inscription est réussie et si votre KeyTalk CKMS a obtenu le bon type de certificat.
- Activez ACME lorsque cela est applicable pour votre nouveau modèle de certificat ClientAuth et notez l’URL unique du serveur KeyTalk ACME
- Configurez, le cas échéant, vos agents ACME existants exécutés sur les points de terminaison hébergeant les applications nécessitant le certificat ClientAuth supplémentaire, pour demander un certificat supplémentaire provenant de l’URL ACME nouvellement activée
- Configurez, le cas échéant, vos agents d’entreprise KeyTalk existants exécutés sur les points de terminaison hébergeant les applications nécessitant le certificat ClientAuth supplémentaire, pour demander un certificat supplémentaire provenant du modèle de certificat nouvellement activé, ET, si nécessaire, mettez à jour les scripts Powershell ou Bash connectés pour appliquer correctement le certificat ClientAuth obtenu à l’application cible
- Testez si les certificats ClientAuth automatisés sont récupérés correctement et appliqués correctement à vos applications cibles.
Avez-vous des questions concernant cet article ou sur la façon dont KeyTalk CKMS vous aide à simplifier la gestion et l’automatisation des certificats numériques ? Notre équipe de support est disponible 24/7 pour vous aider et vous guider dans la mise en place d’une architecture PKI entièrement automatisée par e-mail ou via notre page de contact.
L’équipe KeyTalk
