Le mot de passe est mort. Votre réseau est-il prêt pour son remplacement ?
Votre organisation a passé des années à sécuriser ses accès : pare-feu, VPN, authentification multifacteurs, protection des terminaux. Mais une question plus discrète reste sans réponse pour de nombreuses équipes informatiques : quand un appareil, un serveur ou un service tente-t-il de prouver C'est bien ce qu'il prétend être.Qu'est-ce qui, concrètement, étaye cette affirmation ?
Pour de nombreuses organisations, la réponse honnête est « un mot de passe » ou « une clé API ». Or, ces deux éléments peuvent être volés, obtenus par hameçonnage ou réutilisés par quiconque met la main dessus.
Il existe une meilleure solution, et c'est celle que les navigateurs et les programmes racine exigent désormais : un certificat d'authentification client dédié.
Explorez les options de certificat d'authentification client
Pourquoi est-ce soudainement urgent ?
Voici le changement qui a provoqué ce problème. Depuis le 15 juin 2026, le programme Root de Chrome exige des certificats publics nouvellement émis et approuvés. TLS Les certificats serveur ne doivent plus inclure que l'EKU serverAuth. Mozilla, Apple et Microsoft ont adopté des politiques de programme racine compatibles, mettant ainsi fin à l'utilisation des EKU clientAuth dans les certificats de confiance publics. TLS certificats de serveur.
Si votre organisation réutilisait une norme TLS certificat pour gérer également l'authentification du client ou mutuel TLS (mTLS)Ce raccourci ne fonctionne plus. Tout certificat à double usage servant à la fois d'identité de serveur et de client n'est plus valide pour l'authentification du client et doit être remplacé par un certificat conçu spécifiquement à cet effet, comme celui fourni par SSL.
Toute organisation qui utilise encore un ancien certificat à double usage est déjà en situation de non-conformité aujourd'hui, et les risques ne font que croître si le problème n'est pas résolu. Cela concerne tous ceux qui utilisent l'authentification par certificat pour mTLS, accès Zero Trust, VPN, accès au réseau Wi-Fi, appareils IoT, systèmes de contrôle industriels ou plateformes du marché de l'énergie.
Que fait réellement un certificat d'authentification client ?
Pensez à votre routine habituelle TLS Un certificat sert d'identifiant à votre serveur. Il prouve que le serveur est bien celui qu'il prétend être lorsque votre navigateur s'y connecte. Un certificat d'authentification client inverse ce rôle. Il permet à un appareil, un utilisateur, un serveur ou un service de prouver sa propre identité à l'entité à laquelle il se connecte.
Les mécanismes en jeu sont importants, notamment pour votre entreprise. La clé privée est générée sur l'appareil et n'en sort jamais. Une autorité de certification reconnue (comme SSL) signe uniquement la clé publique, l'associant à une identité vérifiée. Ainsi, aucun mot de passe n'est stocké dans une base de données et exposé au phishing, aucun secret partagé ne risque d'être divulgué en cas de faille de sécurité, et aucune clé API n'est copiée dans un script dont la rotation aurait été oubliée.
La révocation s'applique à chaque certificat individuellement, et non à l'ensemble du parc. En cas de perte d'un ordinateur portable, de cessation d'accès d'un sous-traitant ou de compromission d'un appareil, la révocation du certificat concerné garantit la continuité de service de tous les autres terminaux.
Les principaux avantages, en bref
Voici ce que vous apporte concrètement le passage à un certificat d'authentification client dédié :
- Identité résistante au phishing. La clé privée ne quitte jamais l'appareil, il n'y a donc aucun mot de passe à voler, à réutiliser ou à hameçonner.
- Compatible avec Chrome et les programmes root. Un EKU clientAuth dédié qui répond aux exigences du CA/Browser Forum et du magasin racine, afin que vous ne soyez pas pris au dépourvu par le changement de politique qui a déclenché tout cela.
- Hiérarchie de confiance publique. Émis par le public audité WebTrust de SSL PKI, sans qu'il soit nécessaire de distribuer une racine privée à travers votre pile de parties de confiance.
- Trois niveaux de validation. IV, OV et IV+OV (Sponsor), afin que l'identifiant corresponde à votre politique d'identité et à toutes les exigences réglementaires auxquelles vous êtes soumis.
- Révocation granulaire. Révoquez un seul certificat dès qu'un appareil est perdu, mis hors service ou compromis, sans affecter le reste de votre parc.
- Émission prioritairement basée sur l'API. Résolution à grande échelle dès aujourd'hui grâce à l'API REST de SSL, avec l'automatisation ACME et SCEP/EST en préparation.
Faire correspondre l'identifiant au cas d'utilisation
La validation individuelle (VI) confirme l'identité réelle d'une personne nommée, ce qui la rend idéale pour les appareils des employés, les politiques BYOD et l'accès aux terminaux individuels. La validation d'organisation (VO) confirme l'existence légale d'une entreprise, indispensable pour les serveurs, les machines virtuelles, les comptes de service et les clients API. Enfin, pour les situations nécessitant les deux types de validation, comme les utilisateurs privilégiés, les sous-traitants ou les secteurs réglementés, la VI+VO (validation du parrain) permet d'associer simultanément l'identité de l'individu à l'organisation qui le parraine.
Cette flexibilité est importante car l'authentification du client est présente dans plus d'endroits que la plupart des gens ne le pensent :
|
Case Study |
Niveau de certification |
Compatible avec |
Remarques |
|
mTLS / Confiance zéro |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, passerelle API AWS |
Mutuel TLS; les deux pairs s'authentifient avec X.509 |
|
VPN (basé sur un certificat) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Élimine les VPN à mot de passe ; résistant au phishing |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
Application du NAC ; identifiants sur l’appareil, et non dans un mot de passe |
|
Identité des appareils / IoT |
OV |
AWS IoT Core, Azure IoT Hub, courtiers personnalisés |
Certificat par appareil ; révocation individuelle sans reprogrammation de la flotte |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos ; Piles compatibles avec la norme IEC 62443 |
Authentifie les automates programmables, les interfaces homme-machine et les nœuds d'historisation sur les réseaux OT |
|
Marchés de l'énergie de la NAESB |
IV+OV |
Plateformes conformes NAESB WEQ-12 |
Identifiant requis pour OATI, PowerSecure et autres plateformes EIS |
|
Authentification API Gateway |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
Remplace les clés API et les JWT par une identité de service liée à un certificat |
En plus de ces cas d'utilisation spécifiques, les certificats fonctionnent de manière générale sur l'ensemble de l'infrastructure que votre équipe utilise déjà :
- TLS piles: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL et mbedTLS.
- VPN et accès à distance : Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN et WireGuard (via authentification externe).
- NAC et 802.1X : Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS et Juniper Access Control.
- Passerelles API : Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API Management et Apigee.
- ICS et OT : Plateformes compatibles avec la norme IEC 62443, y compris les couches de découverte et d'authentification des actifs dans Claroty, Nozomi Networks et Dragos.
Délivrance des certificats
Quelle que soit la méthode de délivrance des certificats choisie par votre organisation, SSL propose une solution adaptée :
|
Méthode |
Pour qui c'est |
Fonctionnement |
|
Interface utilisateur Web (tableau de bord ssl.com) |
Administrateurs informatiques, déploiements de petite envergure, émission ponctuelle |
Connectez-vous à ssl.com, sélectionnez Authentification client, choisissez le niveau de validation, terminez la vérification, générez et téléchargez le certificat. Aucune connaissance en programmation n'est requise. |
|
API REST |
DevOps, pipelines CI/CD, provisionnement de flottes à grande échelle |
Commande de certificats par programme, CSR Soumission et téléchargement via l'API REST documentée de SSL. Prend en charge l'émission en masse et l'intégration avec les plateformes d'orchestration. |
|
ACME / SCEP / EST |
Gestion des appareils mobiles d'entreprise, automatisation conforme aux normes IETF (prévue) |
Automatisation du cycle de vie basée sur les protocoles ACME (RFC 8555), SCEP et EST (RFC 7030). En développement — contactez le service commercial pour connaître le calendrier et les modalités d’accès anticipé. |
Comment Acheter
Les certificats d'authentification client sont disponibles directement auprès de SSL sans engagement minimum :
- En libre service. Configurer et acheter en ligne.
- Entreprise et volume. Contactez l'équipe commerciale SSL pour les tarifs dégressifs, la gestion de compte dédiée et NAESB-Intégration spécifique.
- Besoins en hiérarchie privée ou en double EKU. Si vous avez besoin d'une hiérarchie privée, d'un profil de certificat personnalisé ou d'un certificat à double EKU, SSL privé PKI produits purs (Certificats privés à haute garantie, dédiés) PKI, et Entreprise PKI) constituent la bonne voie. Contactez le service commercial pour obtenir une recommandation.
Conclusion
La modification apportée à l'EKU clientAuth n'était pas qu'une simple note technique. Elle a incité les organisations à enfin séparer l'identité du serveur de celle du client, et à remplacer les mots de passe et les clés API par des solutions impossibles à hameçonner ou à rejouer.
SSL exploite une autorité de certification publique auditée par WebTrust depuis plus de 20 ans, et le certificat d'authentification client est la voie directe et conforme à suivre pour toute organisation ayant besoin d'une identité client dédiée à grande échelle, qu'il s'agisse de sécuriser un réseau Zero Trust, une flotte d'appareils IoT ou une plateforme de trading réglementée par la NAESB.
Si vous n'êtes pas certain que votre configuration actuelle repose toujours sur un certificat à double usage, il est temps de le vérifier. La date d'entrée en vigueur étant dépassée, combler cette lacune n'est plus une option, mais nous sommes là pour vous aider.
Votre mTLS Vous êtes concerné par la suppression de l'EKU clientAuth ? Vérifiez vos certificats afin d'identifier l'EKU clientAuth, puis contactez votre service SSL pour envisager une migration vers des certificats d'authentification client dédiés (ou privés). PKI (pour les besoins internes uniquement / double EKU) avant l'expiration de vos certificats actuels:
