Chrome retire le certificat racine eMudhra : comment remplacer les certificats TLS concernés

Chrome doit retirer le certificat racine emSign ECC Root CA–G3 de son magasin de certificats approuvés le 27 octobre, ce qui pourrait perturber les sites dont les certificats TLS aboutissent encore à cette racine. Google a averti que certains certificats légitimes cesseront de fonctionner dans Chrome, notamment ceux qui n’ont jamais été émis par les huit autorités de certification intermédiaires eMudhra compromises.

Le retrait de la racine fait suite à la révélation, le 17 octobre, que les clés privées de huit autorités de certification (CA) intermédiaires eMudhra avaient été générées avec un niveau d’aléa insuffisant et pouvaient être récupérées à partir de leurs certificats publics. Chrome a bloqué ces autorités intermédiaires peu après avoir reçu le signalement, mais le retrait du certificat racine parent impose un remplacement plus vaste des certificats.

Les sites web publics dont les chaînes de certificats aboutissent encore à emSign ECC Root CA–G3 doivent obtenir des certificats de remplacement auprès d’une autre hiérarchie approuvée. Les entreprises doivent également vérifier les intégrations sortantes, les conteneurs, les VPN et les applications qui gèrent indépendamment la confiance accordée aux certificats.

La priorité consiste à identifier les chaînes de certificats concernées, à les remplacer et à vérifier que les services dépendants continuent de fonctionner.

Comment remplacer les certificats TLS eMudhra concernés par le retrait de Chrome

Selon Google, les opérateurs de sites utilisant emSign ECC Root CA–G3 doivent immédiatement obtenir et installer de nouveaux certificats TLS issus d’une autre hiérarchie incluse dans le Chrome Root Store.

Les administrateurs doivent suivre les étapes suivantes :

• Dressez un inventaire. Identifiez les sites web exposés sur Internet, les API, les répartiteurs de charge, les reverse proxies et les autres services qui présentent des certificats TLS. Incluez les services internes, les outils de développement, les conteneurs et les applications susceptibles de dépendre de certificats eMudhra.
• Inspectez la chaîne de certificats effective. Exécutez openssl s_client -showcerts -connect example.com:443 -servername example.com, en remplaçant example.com par le nom d’hôte à vérifier. La commande affiche les certificats présentés par le serveur, qui n’incluent généralement pas le certificat racine.
• Confirmez l’ancre de confiance. Identifiez l’autorité intermédiaire émettrice et déterminez si le certificat remonte jusqu’à emSign ECC Root CA–G3. L’absence de la racine dans la sortie d’OpenSSL ne permet pas d’établir que le service n’est pas concerné.
• Obtenez un certificat de remplacement. Réémettez les certificats concernés par l’intermédiaire d’une autre hiérarchie publique d’autorité de certification approuvée. Installer une autre autorité intermédiaire ne suffit pas si la chaîne obtenue dépend toujours de la racine retirée.
• Déployez le remplacement partout. Mettez à jour les serveurs redondants, les passerelles, les répartiteurs de charge et les autres points de terminaison TLS. Vérifiez que les certificats intermédiaires appropriés sont installés avec le remplacement.
• Testez les connexions dépendantes. Vérifiez l’accès depuis les navigateurs, les appels d’API et les intégrations qui se connectent aux points de terminaison concernés. Ces systèmes peuvent appliquer la confiance accordée aux certificats de manière différente.
• Surveillez après le déploiement. Recherchez les échecs de validation TLS, les avertissements inattendus concernant les certificats et les modifications des chaînes de certificats.

Le remplacement des certificats doit également inclure une vérification de la configuration TLS du service. Les récentes vulnérabilités d’NGINX montrent pourquoi les administrateurs doivent examiner les paramètres liés à TLS et les versions concernées des serveurs, plutôt que de supposer qu’un certificat valide suffit à garantir la sécurité de l’ensemble de la connexion.

Pourquoi un certificat fonctionnel peut malgré tout cesser de fonctionner

Les deux mesures prises concernant eMudhra sont faciles à confondre, mais elles ne sont pas identiques.

Le blocage d’urgence du 17 octobre visait huit autorités de certification intermédiaires précises dont les clés privées pouvaient être récupérées. Six étaient destinées aux certificats TLS, tandis que deux servaient à la signature de code.

Cisco Talos a signalé que plusieurs clés privées comportaient des valeurs à un ou deux chiffres, au lieu de présenter le niveau d’aléa attendu. La récupération des clés devenait ainsi réalisable, créant un risque de falsification de certificats.

La faille est apparue lors d’une cérémonie de génération de clés, le 30 avril 2025. eMudhra a ensuite révoqué les autorités intermédiaires compromises et cessé d’émettre de nouveaux certificats sous sa racine G3.

La mesure prise par Chrome le 27 octobre va plus loin, puisqu’elle consiste à retirer emSign ECC Root CA–G3 lui-même du Chrome Root Store.

Cela signifie qu’un certificat peut être légitime, non expiré et sans lien avec les huit autorités intermédiaires compromises, tout en échouant à la validation dans Chrome si sa chaîne de confiance dépend de la racine retirée.

Cette distinction est importante, car la période de validité d’un certificat ne prime pas sur la décision de confiance d’un navigateur. Les opérateurs qui avaient précédemment confirmé que leurs certificats n’avaient pas été émis par les huit autorités intermédiaires compromises doivent tout de même vérifier la racine parente.

Chrome, Android et les autres plateformes réagissent

Google a bloqué les huit autorités intermédiaires compromises au moyen du mécanisme CRLSet de Chrome le 17 octobre. Cette protection a été distribuée sans nécessiter une mise à jour complète du navigateur.

L’entreprise a parallèlement programmé le retrait d’emSign ECC Root CA–G3 du Chrome Root Store dans la matinée du 27 octobre, heure du Pacifique. Chrome Canary et Beta ont reçu cette modification plus tôt.

Les appareils Android ont reçu des protections contre les certificats intermédiaires compromis via les services Google Play le 19 octobre. Google a indiqué que les utilisateurs pouvaient déclencher immédiatement la mise à jour en redémarrant leurs appareils.

Mozilla a également bloqué les autorités intermédiaires compromises et entrepris de retirer la racine concernée de son magasin de certificats approuvés. Apple a commencé à bloquer les autorités intermédiaires TLS concernées le 19 octobre.

Ces mesures s’attaquent à différents aspects du problème de confiance lié aux certificats. Le blocage des autorités intermédiaires compromises empêche les clients de faire confiance aux certificats émis au moyen de ces clés. Le retrait de la racine affecte un ensemble plus large de chaînes de certificats.

Les entreprises doivent donc vérifier le comportement des certificats sur les navigateurs, les systèmes d’exploitation et les applications qu’elles prennent en charge.

Au-delà du navigateur : ce que les équipes de sécurité doivent vérifier

Les modifications apportées aux navigateurs et aux systèmes d’exploitation n’atteignent pas nécessairement les logiciels qui utilisent leur propre magasin de certificats ou leur propre processus de validation.

Les recommandations de NHS England préconisent d’examiner les dépendances dans les conteneurs, les outils de développement, les appareils IoT, les systèmes opérationnels, les applications mobiles et l’infrastructure PKI interne.

Les VPN et les autres applications qui effectuent leur propre validation TLS peuvent également nécessiter des mises à jour de leurs fournisseurs.

Le langage de programmation Go en fournit un exemple. Son équipe de sécurité a publié Go 1.27.3 et 1.26.10 afin de bloquer les chaînes de certificats impliquant les autorités intermédiaires compromises, le problème étant suivi sous l’identifiant CVE-2026-111943.

Les entreprises utilisant des versions concernées de Go doivent consulter l’avis de sécurité et, si nécessaire, recompiler ou redéployer leurs applications.

D’autres fournisseurs ont attribué des identifiants distincts à des expositions connexes, notamment CVE-2026-91403 pour Oracle Java et CVE-2026-113470 pour Firefox. Les administrateurs doivent suivre l’avis de chaque fournisseur plutôt que de supposer qu’un même correctif s’applique à toutes les plateformes.

La confiance accordée aux certificats peut également dépendre de la manière dont les applications installent ou gèrent les racines approuvées. Par exemple, une faille récemment révélée de Fiddler Classic concernait l’installation d’un certificat racine dans le magasin de certificats de Windows. Bien qu’elle n’ait aucun lien avec eMudhra, elle montre pourquoi la gestion des certificats au niveau des applications doit faire l’objet d’un examen distinct.

Dans le cadre de l’incident eMudhra, les responsables des applications doivent donner la priorité aux systèmes qui intègrent des certificats CA, utilisent des magasins de certificats gérés indépendamment ou exécutent des versions logicielles n’ayant pas reçu les protections correspondantes de leur fournisseur.

Aucune exploitation confirmée, mais les vérifications se poursuivent

Les rapports disponibles des fournisseurs n’ont pas établi d’exploitation malveillante des clés intermédiaires compromises.

Google a indiqué qu’aucun certificat TLS remontant jusqu’aux six autorités intermédiaires concernées n’avait été enregistré dans Certificate Transparency avant leur blocage par Chrome. Par conséquent, les certificats frauduleux issus de ces autorités intermédiaires n’auraient pas pu être acceptés par les clients qui imposent les exigences de Certificate Transparency.

Cisco Talos n’a signalé aucun incident malveillant observé impliquant les certificats compromis au 21 octobre.

eMudhra a également déclaré n’avoir trouvé aucun indice d’une compromission plus large de son infrastructure.

Ces conclusions n’établissent pas qu’un détournement était impossible. Elles décrivent ce que les fournisseurs avaient observé au moment de leurs déclarations.

L’incident montre également pourquoi une connexion HTTPS ne constitue pas, à elle seule, la preuve de la légitimité d’un site web. Comme l’ont montré de précédents articles sur les certificats d’hameçonnage, des attaquants peuvent obtenir des certificats TLS valides pour des domaines qu’ils contrôlent sans compromettre une autorité de certification.

Pour les opérateurs des sites concernés, la tâche immédiate consiste à remplacer les certificats dont la chaîne remonte jusqu’à emSign ECC Root CA–G3 et à confirmer que la nouvelle chaîne est approuvée. Les équipes de sécurité doivent ensuite achever l’examen élargi des dépendances afin d’identifier les applications et les appareils qui pourraient continuer à faire confiance aux autorités intermédiaires compromises.

Google poursuit l’examen des certificats CA restants d’eMudhra. Les administrateurs doivent surveiller les avis des fournisseurs pour repérer d’autres changements de confiance, plutôt que de supposer que le retrait du 27 octobre met fin à l’incident.

À lire également : découvrez les outils de gestion des correctifs disponibles pour coordonner les mises à jour de sécurité sur les systèmes concernés.