Plus de 100 000 faux certificats pour google.com ont été signés avec les clés d'eMudhra

Le certificat porte le nom de google.com et une signature qui se vérifie parfaitement. Pourtant, l'autorité de certification dont il se réclame ne l'a jamais délivré. Entre le 20 et le 21 octobre, 107 107 certificats signés avec six des huit clés compromises d'eMudhra ont été inscrits dans les journaux de transparence d'e-Szignó, des registres publics de certificats de sites web. Plus de 106 000 ne portent que le nom de google.com. Le décompte est du chercheur Jacob Durham, dans le dossier d'incident ouvert par Mozilla.

Ces clés sont celles de huit certificats intermédiaires de l'autorité indienne eMudhra, si mal générées qu'elles se devinaient en 256 essais. Selon Google, elles permettent à n'importe qui de fabriquer un certificat HTTPS pour n'importe quel site, face aux logiciels qui leur font encore confiance. Jacob Durham parle de « preuves de concept ».

Pourquoi votre navigateur ne s'y laisse pas prendre

Chrome a bloqué ces intermédiaires le 17 octobre, moins de deux heures après le signalement, et les autres navigateurs ont suivi dans les trois jours. Surtout, Chrome exige que tout certificat figure dans les journaux de transparence. Or, selon Google, aucun certificat rattaché à ces intermédiaires n'y figurait avant son blocage : aucun faux n'a donc pu le tromper.

Le danger s'est déplacé vers les serveurs et les scripts

Le 25 octobre, eMudhra fait valoir que ses intermédiaires ont été révoqués dans les 14 heures suivant la confirmation. Selon elle, tout logiciel qui vérifie la révocation est donc à l'abri. Une demi-heure plus tard, Jacob Durham lui répond que ces faux certificats, sauf deux, ne contiennent aucune adresse de révocation. Un client qui ne vérifie la révocation que pour le certificat final, configuration courante selon lui, n'a donc rien à vérifier.

Autre obstacle, d'après le chercheur : les serveurs de révocation d'eMudhra refusent les requêtes de curl, de Wget et de bibliothèques de Python et de Perl, très utilisés dans les scripts, mais les acceptent dès que l'outil change de nom. Q Misell, qui l'a constaté de son côté, a ouvert un dossier chez Mozilla, toujours sans réponse d'eMudhra.

Google et eMudhra s'affrontent en public

Le 23 octobre, un représentant d'eMudhra jugeait toute analyse sérieuse « pratiquement impossible » sous la pression des réseaux sociaux, des investisseurs et des clients. Ces explications ne sont pas « acceptables », lui a répondu le programme de certificats racines de Chrome : elles laissent penser que la réputation passe avant les obligations dues aux « milliards » d'utilisateurs exposés. Le 25, eMudhra assume son erreur « sans réserve », mais rappelle que ses clés faibles étaient publiques depuis environ dix-huit mois, et couvertes par des audits, sans que personne ne les repère.

À eMudhra, Jacob Durham rappelle que dès mai 2025, les listes de révocation de ces intermédiaires échouaient à la vérification de signature : examiner alors les clés aurait pu révéler la faille seize mois plus tôt. À Google, il demande pourquoi aucun contrôle ne les a détectées, alors que des membres de son équipe de sécurité ont publié en 2022 un outil capable de les repérer. Google assure avoir vérifié depuis qu'aucune autre clé de ses magasins de confiance ne présente ce défaut.

Que vérifier chez vous ?

Selon ctlogs.dev, qui analyse les journaux de transparence, le risque porte sur les logiciels qui utilisent une liste de certificats ancienne sans vérifier ni la transparence ni la révocation : serveurs, conteneurs bâtis sur d'anciennes images, langages de programmation, équipements embarqués.

• Mettez à jour les magasins de certificats de vos systèmes et langages (ca-certificates, certifi pour Python, Go), versions corrigées dans notre premier article.
• Reconstruisez vos conteneurs à partir d'images de base à jour.
• Si un script vérifie la révocation, une liste inaccessible doit valoir échec, jamais feu vert.
• Si un de vos sites dépend de la racine emSign ECC Root CA – G3, passez à une autre hiérarchie reconnue par Chrome, comme le demande Google.

Google a programmé le retrait de cette racine de Chrome pour le mardi 27 octobre au matin, heure du Pacifique, au prix de certificats légitimes à remplacer, et examine le sort des autres racines d'eMudhra. Prochaine étape : eMudhra doit avoir répondu le 28 octobre aux douze questions de Chrome, selon Jacob Durham.