Le 17 octobre à 20:06 UTC, Mozilla a reçu un signalement, transmis par le programme de racines de Chrome, selon lequel les clés privées de 8 certificats intermédiaires de l'autorité de certification indienne eMudhra étaient compromises ; il comprenait la preuve du contrôle des 8 clés. À 21:48, Mozilla a récupéré les clés par ses propres moyens, sans connaître la méthode de l'auteur du signalement : selon les explications de Mozilla dans l'incident (Bugzilla 2083449), les 8 clés privées P-384 étaient toutes des entiers inférieurs à 256, constitués presque uniquement de zéros, et peuvent être retrouvées presque instantanément. 6 des 8 sont des intermédiaires TLS reconnus par les programmes de racines de Chrome, Mozilla, Microsoft et Apple ; les 2 autres servent à la signature de code et étaient reconnus par Microsoft. Les clés provenaient d'une cérémonie de génération de clés tenue le 30 avril 2025.

Chronologie

  • 17 octobre : Firefox a terminé la mise en défiance des certificats via OneCRL à 22:59 UTC.
  • 18 octobre : à 09:38 UTC, eMudhra a révoqué les 8 certificats (motif caCompromise). eMudhra affirme qu'aucun certificat d'entité finale n'a été émis à partir d'eux, mais comme n'importe qui peut calculer les clés, n'importe qui peut s'en servir pour forger un certificat pour n'importe quel domaine.
  • 20 octobre : Mozilla a annoncé le retrait d'urgence de la confiance accordée à la racine emSign ECC Root CA - G3, afin de protéger les clients qui n'utilisent pas les informations de révocation ou ne peuvent pas retirer leur confiance à des intermédiaires précis ; le programme de racines de Chrome s'est engagé sur une voie similaire le même jour. eMudhra a cessé toute émission depuis les intermédiaires rattachés à cette racine et estimé à environ 30 000 le nombre de certificats à migrer, dont environ 97 % émis via ACME.
  • 22 octobre : eMudhra a annoncé que son conseil d'administration avait décidé de se retirer volontairement du marché mondial des certificats SSL/TLS.

Pourquoi les serveurs ont besoin de leur propre correctif

Les navigateurs disposent de mécanismes de révocation rapides et ont pu bloquer ces certificats d'un simple basculement. Les programmes de votre serveur, c'est autre chose : lorsque curl, wget, Python, PHP, Node, Java ou Go effectuent des requêtes HTTPS, ils s'appuient le plus souvent sur le magasin de confiance du système ou sur une liste de certificats embarquée, et une mise à jour du navigateur ne change rien pour eux. L'analyse publiée par Cloudflare le 20 octobre prévient expressément que mettre à jour un SDK peut ne pas modifier la politique de vérification sous-jacente — tout dépend du magasin de confiance utilisé au bout du compte — et que si des erreurs de certificat apparaissent après correction, il ne faut surtout pas les faire disparaître en désactivant la vérification.

Ce qu'il faut faire sur un VPS

  • Ubuntu : USN-8944-1, publié le 20 octobre, a retiré emSign ECC Root CA - G3 de ca-certificates — 20260816ubuntu0.22.04.1 pour 22.04 et 20260816ubuntu0.24.04.1 pour 24.04 ; USN-8947-1, le 21 octobre, a aussi mis à jour NSS en retirant cette racine ainsi que « Comodo AAA Services root ».
  • Debian : DSA-6572-1 retire les deux mêmes racines, 20250419+deb13u1 pour Debian 13 ; pour Debian 12, c'est DLA-4845-1, 20250419~deb12u2.
  • Après la mise à jour, ls /etc/ssl/certs | grep -i emsign_ecc_root_ca_-_g3 ne doit rien afficher, ce qui signifie que la racine ne figure plus dans le magasin de confiance du système.
  • Les programmes dotés de leur propre liste de certificats doivent être mis à jour séparément : le certifi de Python ne contient plus cette racine depuis la version 2026.10.18 (nous avons vérifié le fichier de certificats inclus, version par version). Sous Linux, les programmes Go utilisent par défaut le magasin de confiance du système, si bien que la mise à jour de ca-certificates couvre la plupart des cas ; pour les cas plus rares où le magasin système n'est pas mis à jour, Go 1.26.10 / 1.27.3, publiés le 19 octobre, ont ajouté une liste de refus à crypto/x509 (GO-2026-6809 / CVE-2026-111943) : recompilez avec une nouvelle version les programmes Go que vous compilez vous-même. Les images Docker embarquent elles aussi leur propre ca-certificates : reconstruisez l'image et redémarrez le conteneur — voir Docker sur un VPS.
  • Redémarrez ensuite les services concernés : les processus déjà en cours d'exécution ne rechargent pas le magasin de confiance.

Cela ne touche pas directement les certificats de la plupart des propriétaires de sites : si vous utilisez Let's Encrypt ou une autre autorité, il n'y a rien à remplacer — voir configurer un certificat SSL Let's Encrypt pour la configuration. Mais l'affaire montre une fois de plus que se protéger contre les faux certificats exige plusieurs niveaux de défense ; la surveillance CT et les enregistrements CAA présentés dans notre article sur les détournements des registres .gh, .sl et .as s'appliquent ici aussi.