Certificats eMudhra compromis : Chrome retire la racine emSign ECC Root CA - G3 le 27 octobre 2026. Comment vérifier vos sites

Les clés privées de huit certificats intermédiaires eMudhra se sont révélées devinables. Les navigateurs les ont bloqués en quelques jours, et Chrome retire maintenant la racine qui se trouve au-dessus. La plupart des sites ne sont pas concernés, mais ceux qui le sont ont jusqu'au mardi 27 octobre.

Ce qui s'est passé

Google, Mozilla et Cloudflare ont chacun publié une chronologie le 20 octobre 2026. Les heures sont en UTC (ajoutez 2 heures pour l'heure de Paris jusqu'au 24 octobre).

La cause est inhabituelle. Ars Technica rapporte que les clés privées retrouvées étaient de tout petits nombres (4, 56, 66, 115, etc.) au lieu de valeurs de 384 bits. eMudhra explique que ces clés viennent d'une cérémonie de génération de clés tenue le 30 avril 2025, au cours de laquelle une erreur a produit un second jeu de clés faibles à côté des clés solides, et que ce sont les clés faibles qui ont servi. eMudhra affirme aussi que son infrastructure n'a pas été compromise.

Google, Mozilla et la page de l'incident indiquent qu'aucun certificat rattaché à ces intermédiaires n'apparaissait dans les journaux Certificate Transparency avant le blocage. Les navigateurs qui imposent Certificate Transparency (Chrome, Firefox, Edge, Safari, selon la page de l'incident) ne pouvaient donc pas être attaqués avec un faux certificat. Pour les logiciels qui ne l'imposent pas, c'est une autre histoire, et c'est pourquoi le nettoyage dépasse largement les navigateurs.

Huit clés, six intermédiaires : la liste exacte

Google parle de huit clés compromises, puis de « ces six autorités intermédiaires ». Les deux chiffres sont justes. Sur les huit intermédiaires, six émettent des certificats TLS (pour les sites web) et deux des certificats de signature de code. BleepingComputer décrit le blocage de Chrome comme portant sur « les six intermédiaires compromis autorisés à émettre des certificats TLS », et la phrase de Google sur les six intermédiaires parle de Certificate Transparency, qui ne concerne que ceux-là.

La liste publique (impacted-intermediates.json sur la page de l'incident) compte 16 entrées pour 8 clés, car chaque intermédiaire existe en deux exemplaires : l'un émis par une racine eMudhra, l'autre contresigné par la racine « AAA Certificate Services » de Sectigo. Les 16 sont révoqués.

Et emSign ECC Root CA - G3 ? La même liste l'indique comme contresignataire des racines eMudhra ci-dessus. C'est la racine que Google désigne comme celle « qui a signé les certificats compromis », et celle qui quitte Chrome le 27 octobre. Les contresignatures Sectigo ne concernent que ces intermédiaires eMudhra : aucune source ne dit que les certificats propres à Sectigo sont touchés.

Qui est concerné le 27 octobre

Deux groupes distincts :

1. 1Les certificats émis par l'un des huit intermédiaires. Ils sont déjà bloqués dans les grands navigateurs depuis le 17-20 octobre. eMudhra affirme qu'aucun de ces intermédiaires n'a émis de certificat final et qu'un seul était en production. Si c'est exact, aucun site n'en utilise.
2. 2Les certificats légitimes qui remontent à emSign ECC Root CA - G3 par d'autres intermédiaires eMudhra. Ce sont eux qui cessent de fonctionner dans Chrome le 27 octobre. Google écrit que « certains certificats légitimes rattachés à cette racine cesseront de fonctionner dans Chrome » et qu'eMudhra s'est engagée à aider ces clients à migrer.

En pratique, la plupart des sites clients d'agence utilisent Let's Encrypt, Sectigo, DigiCert ou le certificat de l'hébergeur, et n'ont rien à faire. La vérification prend une minute par site, et un site concerné affichera une alerte de certificat dans Chrome à partir du 27 octobre.

Navigateur par navigateur

Comment vérifier un site

Dans le navigateur

Cliquez sur l'icône à gauche de la barre d'adresse, ouvrez le détail de la connexion ou du certificat, puis la hiérarchie du certificat (Chrome : onglet « Détails » ; Firefox : « Afficher le certificat »). Lisez chaque niveau, du certificat du site jusqu'à la racine. Si « emSign » ou « eMudhra » apparaît quelque part, poursuivez avec les étapes ci-dessous.

Avec openssl

host=www.example.com
openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

Chaque ligne s: est un certificat envoyé par le serveur, et la ligne i: en dessous indique son émetteur. Les serveurs n'envoient en général pas la racine : la dernière ligne i: donne donc la racine à laquelle la chaîne aboutit. Cherchez emSign, eMudhra ou EM ... TLS CA - G3B/G3C.

Pour vérifier d'un coup une liste de domaines clients, mettez un nom par ligne dans domains.txt :

while read -r host; do
  issuers=$(timeout 10 openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
    | grep -E '^ *i:' | grep -iE 'emsign|emudhra')
  [ -n "$issuers" ] && printf '%s\n%s\n\n' "== $host" "$issuers"
done < domains.txt

Aucune sortie signifie qu'aucun des noms vérifiés ne remonte à un certificat emSign ou eMudhra. N'oubliez pas les autres services TLS : pour un serveur de messagerie, ajoutez -starttls smtp et le bon port (par exemple mail.example.com:587).

Dans les journaux Certificate Transparency

Une recherche du domaine sur crt.sh liste les certificats émis pour lui et ses sous-domaines, avec l'émetteur de chacun. Cela montre ce qui a été émis, pas ce qui est installé, mais c'est un moyen rapide de repérer un certificat emSign sur un sous-domaine oublié.

Derrière un CDN

Avec un CDN, les visiteurs reçoivent le certificat du CDN, et votre serveur d'origine a le sien. Cloudflare demande aux clients en mode Full (strict) de vérifier leurs certificats d'origine, car un certificat d'origine qui n'est plus reconnu coupe la connexion entre Cloudflare et le serveur. Testez aussi l'origine (notre guide sur le certificat valide qui provoque quand même une erreur montre comment tester une adresse IP avec le nom du site).

Que faire si un site est concerné

1. 1Faites émettre un nouveau certificat dans une autre hiérarchie. La consigne de Google est d'« obtenir et installer un nouveau certificat TLS d'une autre hiérarchie PKI présente dans le Chrome Root Store ». Changer seulement le fichier de l'intermédiaire ne sert à rien si tout le chemin mène à la racine retirée. N'importe quelle autorité du Chrome Root Store convient, y compris une autorité ACME gratuite si l'hébergement le permet. Si eMudhra propose un certificat de remplacement, vérifiez avant de l'installer que sa chaîne n'aboutit pas à emSign ECC Root CA - G3.
2. 2Installez la chaîne complète (certificat du site d'abord, puis les intermédiaires) et rechargez le serveur web.
3. 3Testez à nouveau de l'extérieur avec la commande openssl ci-dessus. Les lignes emSign ou eMudhra doivent avoir disparu.
4. 4Recommencez partout où le certificat est servi : autres adresses IP, origine derrière le CDN, serveur de messagerie, répartiteur de charge.
5. 5Faites-le avant le lundi 26 octobre. Le retrait arrive le mardi matin en Californie, soit le mardi après-midi ou en soirée à Paris, et il peut atteindre Chrome Canary et Beta plus tôt.

Vos serveurs et applications font aussi confiance à des certificats

L'autre moitié de l'incident concerne le trafic sortant. Un serveur qui appelle une API de paiement ou reçoit des webhooks valide les certificats avec son propre magasin de confiance, qui peut encore accepter les intermédiaires compromis. Le conseil de Cloudflare : regardez sous le SDK, car la vérification peut être faite par une bibliothèque HTTP, le langage ou le système d'exploitation, et ne « corrigez » jamais de nouvelles erreurs de certificat en désactivant la vérification.

La page de l'incident tient à jour une liste des paquets corrigés. Le 21 octobre, on y trouvait ca-certificates d'Ubuntu et de Debian, ca-certificates 20261020-r0 d'Alpine, NSS 3.131.1, le bundle d'autorités de curl du 2026-10-20, certifi 2026.10.19 pour Python et Go 1.27.3 / 1.26.10, avec Node.js, Bun et FreeBSD encore en attente. Mettez à jour le paquet système, reconstruisez les images de conteneurs et redémarrez les services pour qu'ils chargent le nouveau magasin de confiance.

La checklist rapide

1. 1Listez tous les domaines et sous-domaines clients qui servent du HTTPS.
2. 2Lancez la boucle openssl et cherchez emSign ou eMudhra parmi les émetteurs.
3. 3Consultez crt.sh pour les sous-domaines oubliés, et vérifiez l'origine derrière chaque CDN.
4. 4Remplacez tout certificat concerné par un certificat d'une autre autorité avant le 26 octobre.
5. 5Testez à nouveau de l'extérieur après l'installation.
6. 6Mettez à jour ca-certificates et les environnements d'exécution sur vos serveurs, puis redémarrez les services.

Comment surveiller

Lapsentry se connecte à chaque site et lit le certificat réellement servi. Il affiche l'émetteur à côté de chaque domaine, ce qui permet de passer en revue tout un portefeuille de clients à la recherche d'emSign ou d'eMudhra sans ouvrir chaque site. Une fois le certificat remplacé, l'événement ssl.issuer_changed confirme que le nouveau vient d'un autre émetteur, et ssl.invalid vous alerte si la chaîne ou le nom ne se valident plus, par exemple un intermédiaire oublié lors du changement. Pour une origine derrière un CDN, le test par adresse ci-dessus reste le moyen de vérifier.

Essayer gratuitement pendant 14 jours : sans carte bancaire.

Ce qui n'est pas encore confirmé

Ce guide reflète les sources disponibles le 21 octobre 2026. Restaient ouverts à cette date :

• Apple et Microsoft n'ont rien publié eux-mêmes, à notre connaissance. Les dates de blocage (19 et 20 octobre) viennent de la page de l'incident, et aucun des deux n'a dit s'il retirera emSign ECC Root CA - G3.
• Firefox et la racine. Mozilla retire la racine de NSS 3.131.1 mais ne la nomme pas dans son billet et ne dit pas quand Firefox lui-même cessera de lui faire confiance. Les contournements proposés sur la page de l'incident visent emSign ECC Root CA - G3, ce qui va dans ce sens.
• L'heure exacte du 27 octobre. Google indique seulement « mardi matin, heure du Pacifique ».
• Les autres racines d'eMudhra. Google dit examiner de près « le maintien des autres certificats d'autorité d'eMudhra » dans le Chrome Root Store et publiera ses conclusions sur la liste publique du CCADB.

Nous mettrons cette page à jour si l'un de ces points évolue.

Sources

• Google, Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates, 20 octobre 2026 (en anglais).
• Mozilla Security Blog, Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20 octobre 2026 (en anglais).
• Cloudflare, 8 eMudhra certificates are compromised. Here's what you need to know, 20 octobre 2026 (en anglais).
• Page de l'incident tenue par Dennis Jackson (Mozilla), eMudhra Intermediate CA Compromise, avec impacted-intermediates.json et roots.json, 20 octobre 2026 (en anglais).
• Ars Technica, The Internet goes on high alert after discovery of 8 compromised TLS certs, 20 octobre 2026 (en anglais).
• BleepingComputer, Mozilla, Google, Apple block compromised eMudhra CA certificates, 20 octobre 2026 (en anglais).
• eMudhra, Statement on Recent Certificate Security Incident, 20 octobre 2026, et communiqué du 21 octobre 2026 (en anglais).

FAQ

Qu'est-ce qu'emSign ECC Root CA - G3 ?

C'est un certificat racine exploité par eMudhra, une autorité de certification indienne. Selon la liste publique de l'incident, il a contresigné les racines eMudhra qui ont émis les huit intermédiaires compromis, et Google le désigne comme la racine qui les a signés. Chrome le retire du Chrome Root Store le 27 octobre 2026.

Quand exactement Chrome cesse-t-il de lui faire confiance ?

Google prévoit de déployer le retrait le mardi 27 octobre 2026 au matin, heure du Pacifique, pour tous les appareils qui s'appuient sur le Chrome Root Store, et plus tôt sur Chrome Canary et Chrome Beta. Cela correspond au mardi après-midi ou en soirée à Paris. Prévoyez d'avoir remplacé tout certificat concerné le lundi 26 octobre.

Comment savoir si mon site utilise un certificat eMudhra ?

Regardez la hiérarchie du certificat dans le navigateur, ou lancez openssl s_client avec -showcerts et lisez les lignes d'émetteur. Si emSign ou eMudhra apparaît à un niveau quelconque, le site est concerné. Recommencez pour chaque sous-domaine et pour le serveur d'origine derrière un CDN.

Pourquoi Google parle-t-il de huit clés puis de six intermédiaires ?

Huit intermédiaires avaient des clés faibles : six émettent des certificats TLS pour les sites web et deux des certificats de signature de code. La phrase de Google sur les six intermédiaires porte sur Certificate Transparency, qui ne concerne que les certificats TLS.

Peut-on corriger le problème en changeant le certificat intermédiaire ?

Non. Google demande aux exploitants de sites d'installer un nouveau certificat issu d'une autre hiérarchie PKI présente dans le Chrome Root Store. Si le certificat lui-même remonte à emSign ECC Root CA - G3, il faut le remplacer.

Safari et Edge sont-ils aussi concernés ?

Apple et Microsoft bloquent les intermédiaires compromis, selon la page publique de l'incident, mais au 21 octobre 2026 aucun des deux n'avait annoncé le retrait d'emSign ECC Root CA - G3. Remplacez quand même les certificats concernés : le retrait dans Chrome suffit à casser le site pour les utilisateurs de Chrome.

Les serveurs sont-ils concernés, et pas seulement les navigateurs ?

Oui. Les serveurs, conteneurs et applications qui valident les certificats avec leur propre magasin de confiance peuvent encore accepter les intermédiaires compromis. Mettez à jour ca-certificates et les environnements d'exécution, reconstruisez les images, redémarrez les services, et ne désactivez jamais la vérification des certificats pour faire taire les erreurs.

Autres guides

• Certificat SSL valide mais le navigateur affiche une erreur : cinq causes
• Let's Encrypt passe aux certificats de 64 jours : ce que les agences doivent vérifier
• Durée des certificats SSL : 200, 100, puis 47 jours
• Pourquoi les renouvellements Let's Encrypt échouent