Contexte de la compromission

Le 20 octobre 2026, il a été révélé que les clés privées de huit certificats intermédiaires émis par eMudhra ont été compromises. Ces intermédiaires s’enchaînent vers des autorités racines reconnues par les programmes de confiance de Mozilla, Microsoft, Apple et Chrome, ainsi que par de nombreux magasins de confiance en aval. La compromission d’un intermédiaire permet à un attaquant de signer des certificats pour n’importe quel nom de domaine, ouvrant la voie à des usurpations d’identité sur le Web.

Mécanisme de la démonstration et vérification

Le signalement initial a été effectué par Wayne, qui a signé le texte « We have a problem here - Wayne » avec chaque clé privée compromise. Les fichiers fournis (certificat, clé publique, signature) permettent de reproduire la preuve avec OpenSSL :

openssl x509 -in EM-DV-TLS-CA-G3B.crt.pem -noout -pubkey | diff - EM-DV-TLS-CA-G3B.pub.pem
openssl dgst -sha384 -verify EM-DV-TLS-CA-G3B.pub.pem -signature EM-DV-TLS-CA-G3B.sig message.txt

La correspondance entre la clé publique extraite du certificat et le fichier .pub.pem confirme que la même clé privée a été utilisée pour la signature, attestant de la compromission.

Réaction des programmes racine et des systèmes

Les équipes responsables des programmes racine ont réagi rapidement : les certificats ont été bloqués dans Firefox et Chrome le 17 octobre, dans les appareils Apple le 19 octobre et dans les produits Microsoft le 20 octobre. La révocation a été diffusée via les mécanismes OneCRL (Mozilla), CRLite (Firefox) et CRLSets (Chrome). eMudhra a également révoqué les intermédiaires concernés, mais la plupart des clients ne consultent pas ces listes de révocation sans mise à jour logicielle.

Pour les utilisateurs avancés, des commandes permettent de bloquer manuellement les certificats dans les magasins de confiance des distributions Linux :

# Debian / Ubuntu
sed -i \
  -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \
  -e 's|^mozilla/Comodo_AAA_Services_root.crt|!&|' \
  /etc/ca-certificates.conf && update-ca-certificates

# Alpine
apk add ca-certificates &&
sed -i -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \
  /etc/ca-certificates.conf && update-ca-certificates

# Fedora, RHEL, CentOS, Rocky, Alma, Amazon Linux 2023
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
  /etc/pki/ca-trust/source/blocklist/Comodo_AAA_Services_root.pem &&
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
  /etc/pki/ca-trust/source/blocklist/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-trust

Analyse des impacts et limites de la révocation

La perte d’une clé intermédiaire compromet l’ensemble de la chaîne de confiance sous‑jacente. Un acteur possédant la clé peut générer des certificats valides pour n’importe quel domaine, ce qui rend possible des attaques de type man‑in‑the‑middle ou de phishing à grande échelle. La rapidité de la diffusion des listes de révocation a limité l’exposition : les navigateurs majeurs ont bloqué les certificats en moins de trois jours.

Cependant, la plupart des environnements serveur et des systèmes embarqués ne consultent pas régulièrement les listes CRL ou les filtres de révocation. Sans mise à jour du paquet ca-certificates, ces plateformes continuent de faire confiance aux intermédiaires compromis. Cette situation souligne la dépendance des modèles de confiance aux mécanismes de distribution de révocation et la nécessité d’intégrer des vérifications en temps réel (OCSP stapling, Must‑Staple) dans les déploiements critiques.

En résumé, la compromission d’eMudhra illustre la fragilité d’une hiérarchie de certificats lorsqu’un intermédiaire est exposé. La réponse coordonnée des acteurs du navigateur a limité le risque immédiat, mais la persistance du problème dans les systèmes qui ne consomment pas les listes de révocation montre que la sécurité du TLS repose toujours sur une mise à jour continue des magasins de confiance.