Fin de l'authentification TLS client par les CAs publics : que faire avant 2026
D'ici février 2027, les autorités de certification publiques (CA) cesseront de prendre en charge l'authentification client TLS en raison des nouvelles règles du programme racine de Chrome. Les organisations qui utilisent des certificats SSL/TLS publics pour l'authentification des utilisateurs, des appareils ou des applications devront passer à des CA privées. Ce changement a des répercussions sur les VPN, le mTLS, la connexion Wi-Fi et bien plus encore. Les solutions modernes de CA privées, associées à la gestion du cycle de vie des certificats (CLM), offrent une voie sûre et évolutive pour l'avenir.
En février 2027, un changement fondamental aura lieu dans l'infrastructure à clé publique (PKI), un changement que la plupart des organisations ne suivent pas, mais que beaucoup ressentiront. En raison de la mise à jour des exigences du programme Chrome Root et des récentes annonces des autorités de certification (CA), les autorités de certification publiques ne délivreront plus de certificats prenant en charge l'authentification client TLS.
Pour les organisations qui s'appuient sur ces certificats pour authentifier les utilisateurs, les appareils ou les applications, ce changement introduit une échéance stricte. Les workflows d'authentification existants, en particulier ceux qui s'appuient discrètement sur des autorités de certification publiques gratuites ou automatisées, commenceront à échouer à moins que les organisations ne migrent vers des autorités de certification privées.
Ce changement n'est pas une simple mise à jour de politique. Il s'agit d'un remaniement structurel qui redéfinit la manière dont l'authentification doit être gérée dans l'infrastructure d'entreprise. Et il arrive bien plus tôt que la plupart des gens ne le pensent.
Le changement de politique à l'origine de tout cela
Ce changement trouve son origine dans la politique 1.6 du programme Chrome Root, qui stipule que les hiérarchies de certificats incluses dans le magasin de confiance de Chrome doivent être exclusivement dédiées à l'authentification des serveurs TLS d'ici mars 2027. En bref, les autorités de certification publiques ne seront plus autorisées à émettre des certificats contenant à la fois les utilisations étendues de clés (EKU) id-kp-serverAuth et id-kp-clientAuth. Ces EKU définissent l'usage autorisé d'un certificat, en l'occurrence l'authentification du serveur ou du client.
La mise en œuvre est déjà en cours.
Sectigo a annoncé qu'à compter du 15 septembre 2025, l'EKU d'authentification client ne sera plus incluse par défaut dans les nouveaux certificats SSL/TLS émis. Et d'ici le 10 février 2027, Sectigo supprimera définitivement l'EKU d'authentification client de tous les nouveaux certificats SSL/TLS émis. Après cette date, aucune exception ne sera accordée.
Ce changement de politique s'inscrit dans une tendance plus large des navigateurs à ne plus tolérer les révocations tardives. Plutôt que de continuer à tolérer les certificats publics à usage mixte, Chrome a opté pour la clarté : la PKI publique est réservée à l'authentification des serveurs. Si vous avez besoin d'une authentification client, utilisez une autorité de certification privée.
Qu'est-ce que l'authentification client TLS et pourquoi l'utiliser ?
L'authentification client TLS permet aux systèmes de vérifier l'identité des clients, des utilisateurs, des appareils ou des applications lorsqu'ils tentent de se connecter à un serveur. Elle se distingue de l'authentification serveur TLS (utilisée dans le protocole HTTPS), plus courante, qui vérifie les sites web.
Voici quelques cas d'utilisation courants :
- Accès VPN pour délivrer des certificats aux ordinateurs portables des employés afin de vérifier leur identité lorsqu'ils se connectent à distance.
- Intégration Wi-Fi pour authentifier les appareils des employés et sécuriser les réseaux sans partager de mots de passe statiques.
- Connexion à Salesforce ou autres workflows SSO qui s'appuient sur des certificats clients intégrés aux appareils finaux.
- Mutual TLS (mTLS) pour les API, en particulier dans les pipelines CICD ou entre les microservices dans les architectures zero trust.
- Identité des appareils ou des charges de travail dans les environnements DevOps, y compris les services basés sur des conteneurs.
Le problème principal est le suivant : de nombreuses organisations utilisent sans le savoir des autorités de certification publiques pour l'authentification des clients dans ces workflows, souvent parce que c'est facile, peu coûteux ou fourni avec des outils d'automatisation tels que ACME.
Google Chrome a fait de la suppression de l'authentification des clients une condition préalable pour que les racines restent dans le Chrome Root Store. Comme la plupart des autres navigateurs suivent les mêmes programmes racine, les certificats d'authentification des clients véritablement reconnus à l'échelle mondiale vont disparaître.
Une fois que les principales autorités de certification publiques de confiance auront supprimé les EKU d'authentification client de leurs lignes TLS en 2025/2026, les organisations qui dépendent encore d'un certificat d'authentification client TLS pour identifier leurs clients auront du mal (et bientôt impossible) à trouver des remplacements. Toutes les grandes autorités de certification publiques ont désormais publié un calendrier de suppression progressive.
Les autorités de certification privées modernes : plus aussi lourdes qu'avant
L'authentification client est fondamentalement une fonction de sécurité interne. Elle nécessite de la flexibilité, un contrôle précis et l'assurance que les certificats ne seront pas révoqués par des changements de politique externes. Les autorités de certification publiques n'ont jamais été conçues à cette fin.
Jusqu'à récemment, de nombreuses organisations les utilisaient malgré tout, souvent sans en réaliser les implications. Les certificats publics étaient faciles à obtenir, faciles à automatiser et ne nécessitaient pas de infrastructure PKI interne. Mais ils présentaient des limites :
- Profils de certificats fixes qui ne peuvent pas être modifiés pour s'adapter aux cas d'utilisation internes.
- Audits publics et obligations de conformité imposés par le CA/Browser Forum.
- Aucun contrôle sur les fenêtres d'émission, les critères de révocation ou la politique de cycle de vie.
- Exposition aux changements de politique des navigateurs et des plateformes, comme celui qui se produit actuellement.
En revanche, les autorités de certification privées donnent aux organisations un contrôle total sur l'émission, la conception des profils, la révocation, le renouvellement et l'automatisation. Plus important encore, elles ne sont pas soumises aux contraintes des programmes racines externes. Et aujourd'hui, les solutions d'autorité de certification privée modernes sont beaucoup plus faciles à déployer que par le passé.
Historiquement, les autorités de certification privées avaient la réputation d'être coûteuses, difficiles à gérer et lentes à déployer. Les entreprises devaient construire leur infrastructure PKI à partir de zéro, souvent en s'appuyant sur des outils obsolètes et des processus manuels.
Ce n'est plus le cas aujourd'hui.
Les autorités de certification privées modernes, en particulier celles natives du cloud comme Sectigo, peuvent être provisionnées en quelques minutes, s'adaptent automatiquement et prennent en charge des protocoles tels que ACME, EST et SCEP pour une inscription transparente des certificats. Elles offrent :
- Des profils de certificats personnalisables pour une large gamme de cas d'utilisation interne.
- Des autorités de certification privées par cas d'utilisation, si une séparation des préoccupations est souhaitée.
- Une prise en charge complète des API pour l'intégration dans les plateformes DevOps, MDM et de sécurité.
- L'automatisation du cycle de vie et l'application des politiques grâce aux plateformes de gestion du cycle de vie des certificats (CLM).
Cette évolution est si importante qu'elle a contribué à déclencher le changement de politique de Chrome. Comme l'a fait remarquer Jason Soroko, Senior Fellow chez Sectigo :
« Google se sent en mesure de prendre cette décision car il sait que nous disposons enfin d'options d'autorités de certification privées légères et prêtes à l'emploi. Il y a 15 ans, cela aurait été impossible. »
En d'autres termes, l'infrastructure des autorités de certification privées a enfin rattrapé le problème qu'elle était censée résoudre.
Comment la CLM complète le tableau
Passer à une autorité de certification privée ne consiste pas seulement à remplacer des certificats, mais aussi à prendre le contrôle de la manière dont ces certificats sont gérés.
Avec une durée de vie des certificats SSL/TLS désormais limitée à 47 jours, il n'est plus viable de suivre les certificats à l'aide de feuilles de calcul ou d'espérer que les scripts de renouvellement continuent de fonctionner. La visibilité, l'automatisation et l'application des politiques doivent être intégrées dès le départ.
C'est là qu'intervient la gestion du cycle de vie des certificats (CLM). Une plateforme CLM robuste vous aide à :
- Découvrir tous les certificats de votre environnement, public et privé.
- Classifier et étiqueter les certificats par cas d'utilisation, système et date d'expiration.
- Automatiser la délivrance, le renouvellement et la révocation à grande échelle.
- Appliquer des politiques sur la longueur des clés, l'EKU, les modèles de profil, etc.
- Éviter les interruptions dues à des certificats expirés ou mal configurés.
- Affichez tous vos certificats, privés ou publics, dans une vue unifiée à partir d'un seul et même écran.
Quelle que soit la qualité de votre autorité de certification, sans CLM, vous aurez du mal à rester agile dans un paysage numérique en constante évolution.
« Toutes les routes mènent à la CLM », comme le dit Jason. « Chaque certificat aurait dû être géré dès le départ. »
Que devez-vous faire ensuite ?
1. Cartographiez votre PKI interne
Commencez par identifier où l'authentification client TLS est utilisée dans votre organisation :
- Quels appareils, applications ou services s'authentifient à l'aide de certificats ?
- Quelles autorités de certification les ont émis ?
- Certains de ces certificats sont-ils émis via des workflows ACME publics (par exemple, Let's Encrypt) ?
Si vous n'êtes pas sûr, Sectigo Certificate Manager peut vous aider à découvrir et à inventorier les certificats internes dans les environnements cloud, sur site et hybrides.
2. Évaluez les risques et le calendrier
Comme mentionné précédemment, toutes les autorités de certification publiques devront supprimer progressivement la prise en charge de l'authentification client TLS d'ici février 2027. Tous les certificats prenant en charge l'authentification client émis par ces sources devront être remplacés par des certificats émis par une autorité de certification privée.
3. Déployez une autorité de certification privée moderne
La solution d'autorité de certification privée basée sur le cloud de Sectigo vous permet d'émettre et de gérer des certificats pour :
- L'authentification VPN et Wi-Fi
- Identité des appareils et des charges de travail
- Authentification mTLS et API
- Environnements de développement et pipelines CI/CD
Elle est conçue pour un déploiement rapide et s'adapte à tous les environnements. Grâce à la prise en charge d'ACME, d'EST et de SCEP, ainsi qu'à des intégrations prêtes à l'emploi dans Microsoft ADCS et les plateformes d'identité cloud, vous pouvez mettre en place une PKI privée sans friction infrastructurelle.
4. Automatisez grâce à la gestion du cycle de vie des certificats
Une fois votre autorité de certification privée opérationnelle, l'étape suivante consiste à garantir une visibilité et une automatisation complètes. Sectigo Certificate Manager vous offre :
- Un inventaire complet de tous les certificats (publics et privés)
- Des politiques d'émission basées sur les rôles
- Le renouvellement et la rotation automatiques
- Des alertes d'expiration et la journalisation des audits
La PKI privée n'est plus une option
La suppression progressive de l'authentification client TLS par les autorités de certification publiques n'est pas seulement une mise à jour de la politique, c'est un changement structurel dans la manière dont l'authentification doit être gérée. Elle supprime une béquille sur laquelle de nombreuses organisations s'appuient sans le savoir depuis des années.
La bonne nouvelle, c'est que l'autorité de certification privée n'est plus l'obstacle qu'elle était. Et avec les outils de gestion des certificats qui rattrapent leur retard, le moment n'a jamais été aussi propice pour reprendre le contrôle.
Si vous continuez à transmettre des mots de passe Wi-Fi ou à utiliser des certificats clients provenant d'autorités de certification publiques pour authentifier les ordinateurs portables, il est temps d'agir. L'infrastructure dont vous avez besoin est disponible et la date limite est fixée.
Sectigo offre la solution dont votre organisation a besoin pour rester conforme et agile. Grâce à une autorité de certification privée clé en main, indépendante de toute autorité de certification et à une plateforme sécurisée, simple et évolutive, vous pouvez fusionner vos certificats publics et privés en un seul.
