eMudhra : huit certificats d'autorité compromis

Huit certificats d'autorité intermédiaires de l'autorité de certification indienne eMudhra ont été déclarés compromis le 17 octobre : leurs clés privées pouvaient être retrouvées à partir de données publiques. Navigateurs, systèmes et langages de programmation ont réagi en quelques heures ou quelques jours. Pour les équipes techniques, l'incident impose surtout de vérifier les applications qui embarquent leur propre magasin de certificats.

Des clés générées avec trop peu d'aléa

Selon Google, un chercheur a signalé que les clés privées de ces certificats avaient été générées avec un aléa insuffisant, ce qui permettait à n'importe qui de forger des certificats HTTPS reconnus comme légitimes. Le rapport d'incident de Mozilla, relayé par BleepingComputer, précise que ces clés P-384, créées en avril 2025, pouvaient être retrouvées en testant un très petit nombre de valeurs.

Sur les huit certificats, six étaient habilités à émettre des certificats TLS et deux étaient destinés à la signature de code. eMudhra attribue le problème à une erreur dans un script utilisé lors de la génération des certificats en avril 2025 : un second jeu de clés, plus faible, aurait été sélectionné par erreur. L'entreprise affirme que la plupart de ces certificats n'ont jamais servi en production et qu'elle n'a trouvé aucune trace d'émission vers des clients finaux.

Une riposte en quelques heures

Google indique avoir reçu le signalement le 17 octobre à 18 h 05 UTC et avoir déployé moins de deux heures plus tard une mise à jour CRLSet bloquant les clés concernées dans Chrome, sans redémarrage du navigateur. Android a reçu une protection équivalente via les services Google Play le 19 octobre. Google précise qu'aucun certificat TLS rattaché à ces autorités n'avait été enregistré dans les journaux Certificate Transparency avant le blocage.

Mozilla a reçu l'alerte le même jour à 20 h 06 UTC et a bloqué les certificats via sa liste de révocation OneCRL en moins de trois heures. Le 20 octobre, la fondation a publié Firefox 158.0.1, Firefox ESR 115.43.1 et ESR 153.5.1 pour les installations dont la configuration empêchait la mise à jour automatique de cette liste. La bibliothèque NSS 3.131.1 retire par ailleurs la racine emSign ECC Root CA - G3.

Côté développement, Go a publié le 19 octobre les versions 1.27.3 et 1.26.10, qui contiennent des correctifs de sécurité du paquet crypto/x509. Plusieurs sources spécialisées les associent à cet incident, la CVE-2026-111943. Ces versions arrivent quelques jours après Go 1.27.2 et 1.26.9.

Ce que les équipes doivent faire

• Recompiler les services Go avec 1.27.3 ou 1.26.10 : les binaires embarquent la bibliothèque standard, une simple mise à jour du système ne suffit pas.
• Mettre à jour les magasins de certificats des distributions Linux, de Python (certifi) et des environnements d'exécution comme Node.js, qui ont publié ou préparent des correctifs.
• Vérifier les applications sans contrôle de révocation : un logiciel qui utilise son propre magasin de certificats peut continuer à faire confiance à ces autorités tant qu'il n'est pas mis à jour.
• Changer de certificat si besoin : Google prévoit de retirer emSign ECC Root CA - G3 du Chrome Root Store, avec un déploiement attendu le 27 octobre. Les sites dont le certificat dépend de cette racine doivent en obtenir un nouveau auprès d'une autre autorité.

L'épisode rappelle l'intérêt d'automatiser le renouvellement des certificats, un chantier déjà imposé par la réduction de leur durée de vie à 47 jours.