Le 26 octobre, nous expliquions que les clés privées de huit certificats intermédiaires d'eMudhra pouvaient être calculées directement. Au cours des deux semaines suivantes, plusieurs évolutions ont compté pour les propriétaires de sites : Chrome a retiré emSign ECC Root CA - G3 de son magasin de racines le 27 octobre et a annoncé le 4 novembre des limites pour une autre racine, emSign Root CA - G1 ; Cloudflare a publié le 30 octobre ce qu'il a observé de l'exploitation et des correctifs ; Debian a retiré trois racines d'eMudhra de NSS le 31 octobre ; et Ubuntu a constaté le 5 novembre que les retraits du magasin système n'avaient jamais atteint les magasins de clés Java.

Ce qu'a observé Cloudflare

  • Quelle était la faiblesse des huit clés ? Selon l'analogie de Cloudflare, chacune aurait dû être un nombre à 115 chiffres ; l'une valait en réalité 4, et les autres 56, 66, 115, 155, 156, 230 et 237. N'importe qui peut les calculer à partir des certificats publics et émettre des certificats pour n'importe quel domaine, que les clients non corrigés qui n'imposent pas la transparence des certificats (Certificate Transparency) accepteront.
  • Cloudflare a ajouté une journalisation sur ses connexions sortantes (entièrement déployée le 21 octobre) et a observé en une semaine environ 22 000 poignées de main TLS utilisant les clés faibles. Les deux tiers correspondaient à des accès à des sites de test, et presque tout le reste visait des serveurs d'origine qui semblaient avoir émis leurs propres certificats avec les intermédiaires faibles. Environ 160 poignées de main présentaient des certificats au nom de domaines d'autres organisations, certains liés à des objets connectés grand public ; un certificat forgé était daté du 20 octobre à 18:19 UTC, moins d'une heure après la publication du rapport de bogue de Mozilla. Cloudflare affirme n'avoir à ce jour aucune preuve que ces clés aient servi à intercepter ses connexions.
  • Les correctifs progressent mal : sur quelque 50 millions de sondes, les navigateurs modernes à jour étaient pour la plupart corrigés, mais pas les robots ni les anciens navigateurs ; les navigateurs intégrés comme Android WebView acceptaient encore la chaîne compromise dans 30 à 40 % des cas, et sur les grands réseaux plus de la moitié des sondes l'acceptaient toujours, sans grand changement après le premier week-end.

Ce qu'ont fait ensuite navigateurs et distributions

  • Chrome : pour protéger les utilisateurs du magasin de racines de Chrome qui ne reçoivent pas les mises à jour CRLSet, Google a retiré de ce magasin emSign ECC Root CA - G3, la racine qui a signé les intermédiaires compromis, le changement devant atteindre tous les appareils le matin du 27 octobre (heure du Pacifique). Google indique que les sites dont les certificats remontent à G3 doivent immédiatement en obtenir et en installer de nouveaux.
  • Mise à jour de Chrome du 4 novembre : les certificats de serveur TLS remontant à emSign Root CA - G1 dont le plus ancien horodatage de certificat signé (SCT) est postérieur au 16 novembre 2026 à 23:59:59 UTC ne seront plus approuvés par défaut dans Chrome 153 et versions ultérieures ; les certificats émis avant cette date ne sont pas concernés.
  • Java : selon l'avis USN-9001-1 d'Ubuntu, l'intégration Java de ca-certificates ne fonctionnait pas, si bien que les AC retirées du magasin système n'étaient pas retirées du magasin de clés JKS : les applications Java peuvent donc encore faire confiance à eMudhra. Versions corrigées : ca-certificates 20260816ubuntu0.22.04.2 avec ca-certificates-java 20190909ubuntu1.4 sur 22.04, 20260816ubuntu0.24.04.2 avec 20240118ubuntu0.24.04.1 sur 24.04, et 20260816ubuntu0.26.04.2 avec 20260311ubuntu0.26.04.1 sur 26.04. Redémarrez ensuite les services Java comme Tomcat, Jenkins ou Elasticsearch pour que la correction prenne effet.
  • NSS : l'avis DSA-6599-1 de Debian retire de nss trois racines, « eMudhra emSign Root CA - G3 », « eMudhra emSign Root CA - C1 » et « emSign ECC Root CA - C3 » ; la version corrigée sur Debian 13 est 2:3.110-1+deb13u5. Les programmes qui vérifient les certificats avec NSS (comme Firefox et Thunderbird) dépendent de ce paquet.

N'oubliez pas les programmes qui embarquent leurs propres certificats

De nombreux programmes ne lisent pas le magasin système et embarquent le leur : WordPress 7.1.4, le 28 octobre, a mis à jour ses racines intégrées (voir cet article), et certifi pour Python ainsi que les programmes Go ont été traités dans notre article 85. Le conseil de Cloudflare reste valable : testez après la mise à jour, et ne « corrigez » jamais les erreurs qui en résultent en désactivant la vérification des certificats. Pour comprendre pourquoi la surveillance de la transparence des certificats compte, voir notre article sur les registres détournés ; pour émettre et renouveler les certificats de votre propre site, voir configurer Let's Encrypt SSL.