Huit clés d'AC eMudhra ont été compromises. Voici ce que cela change pour vous

Huit AC intermédiaires eMudhra ont été créées avec des clés privées que n'importe qui peut retrouver à partir du certificat public. Les navigateurs les ont bloquées quelques heures après le signalement du 17 octobre, et les certificats sont désormais révoqués. Nous avons vérifié chaque inventaire dans Red Sift Certificates et Hardenize, et contacté les comptes concernés : ceux qui détiennent des certificats émis sous ces huit AC et ceux qui détiennent des certificats sous l'emSign ECC Root CA - G3, que Firefox et Chrome sont en train de retirer. Si vous exploitez quoi que ce soit qui communique en TLS sans navigateur en frontal, mettez à jour vos magasins de confiance.

eMudhra, l'AC indienne derrière la marque emSign, a mis en place huit nouvelles AC intermédiaires le 30 avril 2025 : six pour les certificats TLS et deux pour la signature de code. Un mois plus tard, Sectigo a contre-signé les huit sous sa racine AAA Certificate Services, si bien que chaque clé figure dans deux certificats qui partagent le même Subject Key Identifier.

Personne n'a eu besoin de voler ces clés. Chacune est une clé à courbe elliptique P-384 dont la valeur secrète est inférieure à 256, et pour l'une d'elles, c'est le nombre 4. Avec le certificat en main, on peut retrouver la clé privée sur un ordinateur portable en bien moins d'une seconde, en essayant chaque valeur tour à tour. eMudhra n'a pas encore confirmé la cause première. Selon son explication préliminaire, un défaut dans le script de la cérémonie des clés a produit une seconde paire de clés, faible, à côté de la paire robuste, et c'est la paire faible qui a été incluse dans les demandes de certificat parce que les libellés se ressemblaient.

Un chercheur a signalé le problème aux programmes racine des navigateurs le 17 octobre 2026, avec un message signé par les huit clés comme preuve. Voici les AC intermédiaires concernées. Chaque empreinte renvoie vers son entrée crt.sh.

• 17 octobre. Un chercheur a signalé les clés aux programmes racine des navigateurs. En quelques heures, Chrome et Firefox ont déployé des mises à jour demandant à chaque navigateur installé de les rejeter, sans nouvelle version du navigateur ni redémarrage nécessaire.
• 18 et 19 octobre. eMudhra, puis Sectigo, ont révoqué les certificats. Apple a déployé le même rejet sur iOS et macOS.
• 20 octobre. Windows a suivi. Mozilla a publié les détails et retiré l'emSign ECC Root CA - G3 de Firefox ; Chrome a annoncé qu'il ferait de même. Mozilla conserve la racine RSA emSign Root CA - G1, que Chrome est encore en train d'examiner.

La bonne nouvelle, c'est que rien n'a été émis sous ces AC avant le blocage. Google a confirmé qu'aucun certificat chaîné à ces AC n'avait jamais été journalisé dans Certificate Transparency, et eMudhra affirme n'avoir émis aucun certificat client.

Chrome, Safari, Firefox et Edge sur ordinateur rejettent un certificat TLS sans preuve CT : une contrefaçon n'aurait donc été acceptée par aucun d'entre eux. Cette protection n'est cependant pas universelle. Mozilla travaille encore sur un problème touchant Firefox pour Android 158.0.1, et les clients qui n'appliquent pas CT n'en bénéficient pas du tout. Depuis la divulgation, des chercheurs ont journalisé plus de 100 000 certificats de démonstration sous ces clés, dont des contrefaçons pour google.com. Voilà à quel point c'est facile.

• Vous détenez un certificat émis par l'une des huit AC. L'AC intermédiaire émettrice est révoquée : la chaîne n'est plus de confiance et les navigateurs la rejettent. Remplacez ce certificat. eMudhra affirme que ce groupe est vide ; vérifiez votre inventaire plutôt que de la croire sur parole.
• Vous détenez un certificat chaîné à l'emSign ECC Root CA - G3. Il n'est pas compromis, mais Firefox ne fait plus confiance à cette racine et Chrome cessera bientôt de le faire. Selon l'estimation initiale d'eMudhra, environ 30 000 certificats doivent migrer vers sa racine RSA, emSign Root CA - G1, que Mozilla conserve. Faites réémettre le vôtre avant que le changement de Chrome n'atteigne vos utilisateurs.
• Votre logiciel se connecte à d'autres serveurs en TLS. C'est le cas de tout le monde. curl, Python, Node.js, Go, Java, les runners CI, les clients d'API, le TLS mutuel et les appareils embarqués font confiance à un bundle de certificats stocké sur disque et ne vérifient pour la plupart ni la révocation ni CT. Un chercheur a forgé un certificat pour une API de paiement bien connue, et curl, Python et Node.js l'ont tous accepté avec leurs paramètres par défaut. Tant que vos bundles ne sont pas mis à jour, les vôtres l'accepteront aussi.
• Vous vérifiez des logiciels Windows signés. Les certificats de signature de code ne sont pas journalisés dans CT : personne ne peut donc lister ce qui a été signé sous les deux AC de signature de code. eMudhra affirme que rien ne l'a été, mais les clés sont faibles depuis le 30 avril 2025, si bien qu'un horodatage ne prouve rien. Considérez tout ce qui a été signé sous ces AC comme non fiable.

Le 21 octobre, nous avons recherché dans chaque inventaire de Red Sift Certificates et Hardenize les certificats émis sous les huit clés, en effectuant la correspondance sur l'identifiant de clé de l'émetteur et sur les empreintes de chaîne des seize certificats. Nous en avons trouvé une poignée, aucun sur un service en production, tous journalisés après la divulgation par des chercheurs qui testaient les clés retrouvées. Nous avons aussi recherché les certificats sous la racine ECC G3. Nous avons contacté chaque compte de l'un ou l'autre groupe.

Vous pouvez vérifier par vous-même. Le widget Certificate Authorities de votre tableau de bord, ci-dessous, liste les AC à l'origine de vos certificats. Si eMudhra y apparaît, ouvrez ces certificats, comparez le SHA-256 de l'AC émettrice avec le tableau ci-dessus et regardez à quelle racine aboutit la chaîne. Seuls les certificats émis sous les huit AC intermédiaires sont compromis. Les certificats sous la racine ECC G3 ne le sont pas ; ils devront être réémis. Les certificats InCommon émis depuis avril 2026 apparaissent aussi comme eMudhra, car leurs AC intermédiaires sont émises sous la racine G1 d'eMudhra ; ils ne nécessitent aucune action.

• Mettez à jour les magasins de confiance partout. Mettez à jour les paquets CA du système d'exploitation, Python certifi, Node.js, Java cacerts, Homebrew et les magasins de confiance embarqués. Recompilez vos binaires Go avec une chaîne d'outils corrigée et vos conteneurs avec des images de base et des dépendances à jour, puis redéployez.
• Bloquez les AC compromises. Vérifiez le mTLS, les VPN, les passerelles d'API et l'épinglage de certificats. Rejetez les clés concernées à la fois via les chaînes eMudhra et via les chaînes contre-signées par Sectigo ; supprimer une AC intermédiaire mise en cache ne suffit pas.
• Faites réémettre les certificats chaînés à l'emSign ECC Root CA - G3. Remplacez-les par des certificats chaînés à une racine de confiance avant que le changement de Chrome n'atteigne vos utilisateurs.
• Laissez la vérification activée. Analysez les erreurs de certificat qui apparaissent après les mises à jour au lieu de désactiver les contrôles.
• Testez le chemin réel. Vérifiez que l'application elle-même rejette les chaînes compromises. Un test dans un navigateur ou avec curl sur un portable ne prouve pas qu'un service en production est protégé.
• Identifiez les appareils que vous ne pouvez pas mettre à jour. Restreignez leur accès réseau. Lorsque c'est possible, utilisez une passerelle à jour qui termine le TLS et valide les certificats en amont. Un pare-feu seul ne suffit pas.

Red Sift Certificates tient un inventaire en temps réel de chaque certificat de votre parc, avec la chaîne réellement envoyée par chaque serveur : un incident d'AC devient ainsi une simple recherche plutôt qu'une course contre la montre. Le widget Certificate Authorities montre de quelles AC vous dépendez, et la surveillance Certificate Transparency vous indique quand un nouveau certificat est émis pour vos domaines, et par qui.

Si vous n'êtes pas encore client de Red Sift Certificates et souhaitez savoir si un certificat de vos domaines est chaîné à ces AC, demandez une démo gratuite.

• eMudhra Intermediate CA Compromise: page de divulgation et site de test
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates (inclut la déclaration du Chrome Root Program)
• Bugzilla 2083449: Private key compromise of eMudhra Intermediate Certificates
• Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know
• Scott Helme: Eight bits of trust, eMudhra's CA keys cracked in milliseconds