FiveM
Minecraft
Rust
RedM
HytaleHuit certificats intermédiaires eMudhra compromis
Le 17 octobre 2026, un chercheur en sécurité indépendant a découvert que huit certificats intermédiaires émis par l'autorité de certification indienne eMudhra (marque emSign) reposaient sur des clés privées si faibles qu'elles pouvaient être retrouvées en moins d'une seconde. Ces clés, générées sur la courbe elliptique NIST P-384, auraient dû être des nombres aléatoires de 384 bits. En réalité, leurs valeurs effectives étaient toutes inférieures à 256 : la plus faible valait 4 (source : Google Security Blog).
Quiconque pouvait tester les 256 possibilités et retrouver la clé privée, puis signer n'importe quel certificat SSL/TLS au nom d'eMudhra. Si vous administrez un VPS Linux ou un serveur dédié, votre système fait confiance à ces certificats numériques via le paquet ca-certificates. Tant que le trust store n'est pas mis à jour, des outils comme curl, wget, apt ou vos applications PHP, Python, Node.js et Go peuvent accepter un faux certificat de serveur signé avec ces clés compromises.
Rappel : la chaîne de confiance des certificats SSL/TLS
Le protocole SSL/TLS sécurise les échanges entre un client et un serveur web en deux temps : authentification du serveur (le client vérifie que le certificat de serveur est signé par une autorité de confiance) et chiffrement de la connexion (les données transitent chiffrées entre les deux machines). Chaque certificat SSL contient une clé publique et l'identité du nom de domaine qu'il protège.
La confiance repose sur une hiérarchie. Une autorité de certification (CA) racine signe un certificat intermédiaire, qui signe à son tour le certificat de serveur présenté au navigateur ou au client TLS. Si la clé privée d'un certificat intermédiaire est compromise, un attaquant peut fabriquer un certificat signé pour n'importe quel nom de domaine. Le navigateur ou le serveur qui fait confiance à la racine acceptera cette connexion comme sécurisée, sans avertissement. C'est exactement le scénario rendu possible par la faille eMudhra.
Les certificats concernés
Les huit intermédiaires compromis, tous créés lors d'une même cérémonie de clé le 30 avril 2025, se répartissent en six certificats TLS et deux certificats de signature de code :
| Certificat intermédiaire | Type | Usage |
|---|---|---|
| EM DV TLS CA - G3B | TLS (Domain Validation) | Certificat SSL pour un nom de domaine |
| EM DV TLS CA - G3C | TLS (Domain Validation) | Certificat SSL pour un nom de domaine |
| EM OV TLS CA - G3B | TLS (Organization Validation) | Certificat SSL d'organisation |
| EM OV TLS CA - G3C | TLS (Organization Validation) | Certificat SSL d'organisation |
| EM EV TLS CA - G3B | TLS (Extended Validation) | Certificat SSL à validation étendue |
| EM EV TLS CA - G3C | TLS (Extended Validation) | Certificat SSL à validation étendue |
| EM OV CS CA - G3B | Signature de code | Certificat de signature numérique |
| EM OV CS CA - G3C | Signature de code | Certificat de signature numérique |
Les valeurs effectives des huit clés privées P-384 étaient : 4, 56, 66, 115, 155, 156, 230 et 237. Chaque intermédiaire possédait aussi une variante cross-signée par Sectigo (racine AAA Certificate Services), soit 16 certificats affectés au total. eMudhra estime qu'environ 30 000 certificats ont été émis par ces intermédiaires, dont 97 % via le protocole ACME (source : Kudelski Security).
Origine de la faille
D'après eMudhra, le problème provient d'un script de cérémonie de clé défaillant utilisé le 30 avril 2025. Le script a généré un second jeu de clés de test avec des valeurs triviales. Les libellés de ces clés de test ressemblaient trop à ceux des clés valides, et l'opérateur a signé les demandes de certificat (CSR) avec le mauvais jeu. Résultat : huit clés privées NIST P-384 dont la valeur tient dans un seul octet, exposées dans les certificats publics pendant environ 17 mois avant qu'un chercheur indépendant ne les repère. La vulnérabilité est référencée CVE-2026-111943.
La clé publique correspondante était bien une courbe P-384 valide en apparence, ce qui rendait la faille invisible à l'inspection visuelle du certificat de l'autorité intermédiaire. Seule une analyse numérique du scalaire privé (la valeur secrète derrière la clé publique) révélait que le chiffrement reposait sur un nombre ridiculement petit.
Chronologie de la réponse
| Date (UTC) | Événement |
|---|---|
| 30 avril 2025 | Cérémonie de clé : les huit intermédiaires sont créés avec des scripts de génération défectueux |
| 17 octobre 2026 | Le chercheur "Wayne" signale la faille à Mozilla, Apple, Google, Microsoft et eMudhra |
| 18 octobre 2026 | eMudhra révoque les huit intermédiaires |
| 19 octobre 2026 | Sectigo révoque les variantes cross-signées ; Apple bloque les certificats |
| 20 octobre 2026 | Mozilla retire emSign ECC Root CA - G3 de NSS 3.131.1 ; Microsoft bloque les intermédiaires ; Google déploie une mise à jour CRLSet dans Chrome ; Ubuntu publie l'avis de sécurité USN-8944-1 |
| 21 octobre 2026 | Debian publie l'avis DSA-6572-1 ; Red Hat publie RHSB-2026-012 |
Vérifier si votre serveur Linux est concerné
Les navigateurs web (Chrome, Firefox, Safari, Edge) ont intégré le blocage automatiquement. En revanche, sur un serveur Linux administré en ligne de commande, c'est le paquet ca-certificates qui gère le trust store du système. Les serveurs web comme Apache ou Nginx, les services de base de données (MySQL, PostgreSQL), les serveurs de messagerie SMTP (Postfix, Exim) et tous les scripts qui établissent des connexions sécurisées TLS sortantes s'appuient sur ce trust store.
Ouvrez un terminal sur votre VPS ou serveur dédié et exécutez la commande suivante pour rechercher la présence de la racine emSign dans le magasin de certificats :
grep -r "emSign" /etc/ssl/certs/Si la commande renvoie des résultats, votre serveur fait encore confiance aux certificats de l'autorité compromise. Vérifiez ensuite la version du paquet avec la commande suivante :
dpkg -l ca-certificatesLes versions corrigées sont 20260816ubuntu0.24.04.1 (Ubuntu 24.04), 20260816ubuntu0.22.04.1 (Ubuntu 22.04), 20260816ubuntu0.26.04.1 (Ubuntu 26.04) et 20250419+deb13u1 (Debian 13). Si votre version est antérieure, le correctif n'est pas encore installé.
Pour inspecter la chaîne de confiance d'un certificat distant, utilisez openssl s_client comme décrit dans notre guide vérifier un certificat TLS avec OpenSSL. Cette commande affiche le certificat de serveur, le certificat intermédiaire et la racine, ainsi que l'adresse IP du serveur distant et le nom de domaine du certificat.
Mettre à jour le paquet ca-certificates
Sur Ubuntu, les correctifs sont disponibles via les avis de sécurité USN-8944-1 (Ubuntu 22.04 à 26.10) et USN-8944-2 (Ubuntu 14.04 à 20.04). Sur Debian, le correctif est l'avis DSA-6572-1. Sur Red Hat Enterprise Linux, l'avis RHSB-2026-012 couvre RHEL 6 à 10. Ces mises à jour retirent la racine emSign ECC Root CA - G3 du trust store système, et la racine AAA Certificate Services (Sectigo) sur les versions antérieures à Ubuntu 22.04.
Connectez-vous en SSH à votre serveur et exécutez la commande suivante en ligne de commande :
sudo apt update
sudo apt install --only-upgrade ca-certificatesAprès la mise à jour, vérifiez que la racine a été retirée :
grep -r "emSign" /etc/ssl/certs/La commande ne doit plus renvoyer de résultat. Si vous utilisez un serveur web Apache ou Nginx pour servir vos sites, les nouvelles connexions TLS utiliseront le trust store corrigé sans redémarrage : le trust store est lu à chaque connexion entrante. En revanche, les connexions persistantes (keep-alive) déjà établies ne seront pas affectées avant leur expiration.
Correctif manuel si le paquet corrigé n'est pas encore disponible dans vos dépôts. La commande suivante désactive la racine emSign dans le fichier de configuration des certificats de confiance, puis régénère le bundle :
sudo sed -i 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' /etc/ca-certificates.conf
sudo update-ca-certificatesCette commande préfixe la ligne de la racine emSign d'un ! dans le fichier de configuration, ce qui la désactive. update-ca-certificates régénère ensuite le bundle dans /etc/ssl/certs/ca-certificates.crt, utilisé par les serveurs web, les clients TLS et les applications du système.
Pourquoi apt upgrade seul ne suffit pas toujours
Un sudo apt upgrade met à jour les paquets pour lesquels une nouvelle version existe dans vos dépôts. Deux situations courantes peuvent l'empêcher de corriger ce problème :
- Les dépôts de sécurité ne sont pas configurés dans
/etc/apt/sources.list(la source-securityest absente ou commentée). Vérifiez que la lignedeb http://security.ubuntu.com/ubuntu(Ubuntu) oudeb http://security.debian.org/debian-security(Debian) est bien active. - Le paquet
ca-certificatesest retenu (held) par une configuration dpkg ou apt, ce qui bloque sa mise à jour lors d'unapt upgradeclassique.
La commande ciblée apt install --only-upgrade ca-certificates est plus fiable : elle force la mise à jour de ce paquet précis, indépendamment des autres paquets en attente. Si vous avez configuré les mises à jour de sécurité automatiques (unattended-upgrades) sur votre VPS, le correctif sera appliqué automatiquement après sa publication dans les dépôts de votre distribution.
Les conteneurs Docker sont aussi concernés
Les images Docker basées sur Debian ou Ubuntu embarquent leur propre copie du trust store. Mettre à jour ca-certificates sur l'hôte ne corrige pas les conteneurs existants. Pour chaque image :
- Reconstruisez vos images en ajoutant
RUN apt-get update && apt-get install -y ca-certificatesdans le Dockerfile. - Si vous utilisez des images officielles (nginx, node, python), tirez la dernière version avec
docker pullet redéployez.
Si vous gérez vos conteneurs avec Docker Compose, un docker compose build --pull --no-cache suivi d'un docker compose up -d suffit à reconstruire et redéployer avec le trust store corrigé.
Applications avec bundle de certificats intégré
Certains langages embarquent leur propre liste de certificats numériques de confiance, indépendante du trust store système. Même après la mise à jour de ca-certificates, ces applications peuvent encore faire confiance à la racine compromise :
- Go : les versions 1.27.3 et 1.26.10+ retirent la racine emSign (CVE-2026-111943).
- Python (certifi) : la version 2026.10.20 ou ultérieure retire emSign ECC Root CA - G3. Mettez à jour avec
pip install --upgrade certifi. - Java / Tomcat : le trust store Java (
cacerts) est séparé du système. Si vous exécutez un serveur Tomcat ou une application Java sur votre serveur, vérifiez que le certificat de l'autorité emSign n'est pas dans le keystore aveckeytool -list -keystore $JAVA_HOME/lib/security/cacerts | grep -i emSign. Pour le retirer :keytool -delete -alias emsignecc -keystore $JAVA_HOME/lib/security/cacerts. - Rust (webpki-roots) : vérifiez que votre crate utilise une version postérieure au 20 octobre 2026.
- Perl (Mozilla::CA) : le module suit le programme Mozilla. Mettez-le à jour via CPAN (CVE-2026-113812).
Si vos services tournent derrière un reverse proxy qui gère la terminaison TLS, seul le proxy a besoin du trust store à jour. Notre guide Certbot et Let's Encrypt sur VPS Linux détaille comment installer un certificat TLS valide pour chiffrer les connexions entre vos visiteurs et votre serveur web.
Services serveur à vérifier : Apache, MySQL, SMTP et autres
Au-delà du navigateur et des outils en ligne de commande, de nombreux services installés sur un serveur virtuel (VPS) ou dédié établissent des connexions TLS sortantes qui reposent sur le trust store système. Si votre admin système n'a pas mis à jour ca-certificates, ces services restent exposés :
| Service | Protocole SSL/TLS utilisé | Vérification |
|---|---|---|
| Apache / Nginx | HTTPS (port 443) | Le serveur web utilise le trust store pour les connexions sortantes (reverse proxy, requêtes vers des API externes) |
| MySQL / MariaDB | TLS sur port 3306 | Configurer ssl-ca dans my.cnf ; les réplications chiffrées entre serveurs vérifient le certificat de l'autorité distante |
| PostgreSQL | TLS sur port 5432 | Le paramètre sslrootcert pointe par défaut vers le bundle système ; les connexions sécurisées sslmode=verify-full valident le nom de domaine du serveur distant |
| Postfix / Exim | SMTP avec STARTTLS (port 587) | Les serveurs de messagerie SMTP vérifient le certificat TLS du serveur distant lors de l'envoi ; smtp_tls_CAfile dans Postfix pointe vers le bundle système |
| vsftpd / ProFTPD | FTP sur TLS (FTPS) | Les transferts de fichiers chiffrés via le protocole FTP sécurisé vérifient le certificat de serveur distant |
| PHP (curl, file_get_contents) | HTTPS | Les scripts PHP qui appellent des API externes utilisent le trust store système via openssl.cafile dans php.ini |
Après la mise à jour du paquet ca-certificates, ces services utilisent automatiquement le nouveau bundle. Il n'est pas nécessaire de redémarrer Apache, Nginx ou les autres services pour que les nouvelles connexions TLS sortantes utilisent le trust store corrigé. En revanche, si vous avez configuré un chemin personnalisé vers un fichier de certificat de l'autorité (directive SSLCACertificateFile dans Apache, ssl_client_certificate dans Nginx), vérifiez que ce fichier ne contient pas encore la racine emSign.
Faut-il installer un nouveau certificat sur votre serveur ?
Non. La mise à jour de ca-certificates retire une racine du trust store, elle n'en ajoute pas. Votre propre certificat SSL/TLS (celui qui protège votre nom de domaine, émis par Let's Encrypt, DigiCert ou une autre autorité) n'est pas concerné par cet incident. Vous n'avez pas besoin de demander un nouveau certificat, d'ajouter un certificat de remplacement ni de modifier les enregistrements DNS de votre domaine.
Le seul cas où une action supplémentaire est nécessaire : si votre serveur utilise un certificat émis par eMudhra (emSign). Dans ce cas, ce certificat n'est plus reconnu par les navigateurs et les clients TLS. Vous devez alors demander un nouveau certificat auprès d'une autre autorité de certification. Pour installer un certificat Let's Encrypt gratuitement, suivez notre guide Certbot et Let's Encrypt sur VPS Linux.
Ce qu'il faut retenir
La compromission des clés privées d'eMudhra n'a pas provoqué d'attaque connue à ce jour, mais les clés étaient récupérables depuis 17 mois. Les navigateurs ont réagi en quelques heures. Les serveurs Linux, eux, ne bénéficient pas de ces mises à jour automatiques du trust store. Si vous administrez un VPS ou un serveur dédié :
- Mettez à jour le paquet
ca-certificatesimmédiatement avec la commandesudo apt install --only-upgrade ca-certificates. - Vérifiez que la racine emSign a disparu du trust store avec
grep. - Reconstruisez vos images Docker.
- Mettez à jour les applications qui embarquent leur propre bundle de certificats numériques (Go, Python certifi, Java/Tomcat, Rust webpki-roots, Perl Mozilla::CA).
- Vérifiez les services serveur (MySQL, PostgreSQL, Postfix, Apache) qui utilisent le trust store pour chiffrer leurs connexions sortantes.
Pour renforcer la sécurité de votre infrastructure, consultez nos guides sécuriser un VPS Ubuntu, sécuriser SSH sur VPS Linux et configurer un reverse proxy Nginx.