Un site peut afficher une connexion HTTPS alors que le logiciel utilisé lui accorde sa confiance à tort. L’incident eMudhra illustre pourquoi la sécurité des connexions dépend aussi des autorités de certification et des mises à jour de nos outils.
Point de situation au 26 octobre 2026. Les mesures ci-dessous distinguent les protections annoncées par les éditeurs des vérifications à effectuer dans chaque environnement. Les avis officiels peuvent évoluer.
Que s’est-il passé ?
Des clés privées d’autorités intermédiaires eMudhra ont été produites avec trop peu d’aléatoire. Elles pouvaient être retrouvées à partir des informations publiques, permettant de signer de faux certificats. Le problème concernait la génération de ces clés, et non une démonstration que l’algorithme cryptographique P-384 était cassé. Avis du CERT-In.
Apple détaille huit autorités intermédiaires touchées : six pour TLS et deux pour la signature de logiciels. Chaque intermédiaire TLS avait deux certificats, dont une signature croisée Sectigo : douze certificats TLS, mais six clés TLS. Explications d’Apple.
Le 26 octobre, eMudhra reconnaît une erreur de script. L’entreprise affirme n’avoir constaté aucune compromission de ses infrastructures ou des données de ses clients dans son enquête et annonce une publication de ses conclusions. Ces déclarations de l’émetteur ne suffisent pas à établir l’absence d’exploitation partout ailleurs. Déclaration d’eMudhra.
Racine, intermédiaire, certificat du site : qui fait quoi ?
Le logiciel qui ouvre une connexion doit décider s’il peut faire confiance au certificat présenté. Une chaîne habituelle relie trois rôles, décrits dans le standard des certificats X.509 :
Autorité racine : sert de point de confiance reconnu par le système ou l’application.
Autorité intermédiaire : reçoit une délégation de certification et signe d’autres certificats. Une chaîne peut comporter plusieurs intermédiaires.
Certificat du site : associe notamment une clé publique aux noms de domaine du service.
La vérification porte sur cette chaîne et les règles de confiance du logiciel. Dans cet incident, les clés faibles appartenaient aux intermédiaires. Retirer ensuite la confiance à une racine est une mesure de protection ; cela ne signifie pas que sa propre clé privée a été découverte. Pour le principe des points de confiance, voir la documentation DigiCert.
Quel était le risque réel ?
Un attaquant interceptant une connexion pouvait usurper le site attendu et lire ou modifier les échanges si le logiciel acceptait encore la chaîne compromise. Cela ne lui donnait pas automatiquement accès au serveur légitime ou à sa base de données. Analyse de Mozilla.
Il faut distinguer une capacité d’attaque d’une attaque constatée. Un inventaire de logiciels vulnérables ne prouve pas qu’ils ont été exploités. Inversement, l’absence d’alerte visible ne valide pas leur configuration. Red Hat décrit notamment la confiance encore accordée aux autorités concernées et la position de l’attaquant sur le réseau parmi les conditions d’exposition. Avis Red Hat.
Comment une attaque pouvait-elle se dérouler ?
Imaginez une employée qui ouvre le portail de son entreprise. Elle saisit la bonne adresse, mais sa connexion passe par un équipement contrôlé par un attaquant. Le scénario suivant illustre le mécanisme possible ; il ne décrit pas une attaque constatée chez Nuagerie.
- Obtenir le pouvoir de signer. Une clé intermédiaire compromise permet de produire des signatures que le client pourrait encore accepter.
- Préparer une fausse identité. L’attaquant crée sa propre clé de serveur et un certificat portant le nom du portail.
- Intercepter la connexion. Un accès au trajet réseau reste nécessaire, par exemple à travers une passerelle compromise. Le certificat seul ne redirige aucun trafic.
- Faire accepter cette identité. Le logiciel client doit encore considérer la chaîne comme valable et ne pas bloquer le certificat selon ses autres règles.
- Se placer entre les deux parties. L’attaquant peut établir une seconde connexion vers le vrai portail et relayer les échanges. Il devient alors une extrémité de chaque connexion chiffrée.
Ce dernier point explique pourquoi le chiffrement peut fonctionner alors que l’interlocuteur est le mauvais. Le modèle à deux connexions est décrit par OWASP ; la validation de la chaîne relève des règles X.509.
Les dates à retenir
17 octobre 2026 : signalement et blocages dans Chrome et Firefox. Google, Mozilla.
18 octobre : révocation des intermédiaires, selon le CERT-In.
19 octobre : début du blocage des certificats TLS concernés sur les appareils Apple. Apple.
20 et 21 octobre : avis publics ; le 21, Mozilla corrige l’application du blocage sur certains clients Firefox Android. Mozilla.
27 octobre : date prévue par Google pour retirer la racine emSign ECC Root CA - G3 de Chrome sur tous les appareils, après les canaux de préversion. Au 29 octobre, Google n’avait pas publié de confirmation distincte du déploiement ; un site encore rattaché à cette racine devrait changer de chaîne sans attendre. Google.
Avant le blocage, Google n’avait trouvé aucun certificat TLS des six intermédiaires concernés dans les journaux de transparence (CT). Cette protection supplémentaire concerne les clients imposant CT. Précisions de Google.
Que faire selon votre situation ?
Vous utilisez un ordinateur ou un téléphone
Installez les mises à jour proposées pour votre système, votre navigateur et vos applications. Si une application demande de redémarrer, faites-le. En cas d’avertissement de certificat, relevez l’adresse, le message et l’heure, puis utilisez un canal connu pour joindre l’équipe responsable. Notre guide sur les avertissements SSL explique les premières vérifications.
Apple distingue ses protections pour Safari des outils en ligne de commande ou applications utilisant d’autres listes de confiance. Vérifier le navigateur ne suffit donc pas pour conclure sur tout le poste. Portée des protections Apple.
Vous êtes responsable d’un site Web
Demandez à votre hébergeur ou administrateur de vérifier la chaîne réellement présentée. Pour un site rattaché à cette racine G3, Google demande une nouvelle chaîne reconnue. Cette consigne ne vise pas tous les sites. Consigne de Google.
Pour préparer cette vérification, regroupez vos domaines, sous-domaines, services d’hébergement et éventuels CDN. Identifiez qui peut intervenir et demandez une confirmation du résultat après changement. Notre guide pour configurer et maintenir HTTPS aide à organiser ces étapes.
Vous gérez des serveurs, applications ou conteneurs
Repérez le composant qui valide réellement les certificats : système, environnement d’exécution, bibliothèque HTTP ou liste embarquée. Cloudflare souligne qu’une mise à jour du SDK seul peut laisser inchangée la politique de vérification utilisée en dessous. Ses recommandations couvrent aussi les images de conteneurs et les dépendances. Conseils techniques de Cloudflare.
Nous recommandons de suivre chaque intervention avec quatre éléments : le composant concerné, le correctif appliqué, son déploiement effectif et un test des connexions utiles. Incluez les tâches planifiées et les intégrations, même si personne ne les ouvre dans un navigateur. Consultez les instructions propres à vos produits, notamment les mesures Red Hat.
Ne désactivez pas la vérification TLS pour faire disparaître une erreur après une mise à jour. Cloudflare rappelle que cela retire justement la protection d’authentification recherchée. Faites examiner le certificat, sa chaîne et la configuration de confiance. Cloudflare.
Pour les équipes techniques : CAA, transparence et TLS
Un enregistrement DNS CAA indique quelles autorités peuvent émettre pour un domaine. C’est une règle vérifiée pendant l’émission, pas un verrou cryptographique sur la clé de signature. Nous en déduisons qu’une personne signant directement avec une clé compromise ne passe pas par ce contrôle normal. Fonctionnement de CAA.
Certificate Transparency rend les émissions observables. Un certificat journalisé n’est pas pour autant légitime. Le refus d’un certificat sans preuve CT dépend aussi de la politique du client ; journalisation, blocage et révocation ont des rôles différents. Principe de CT.
Enfin, posséder une clé de certification ne permet pas à lui seul de déchiffrer des sessions TLS 1.3 enregistrées auparavant avec un échange éphémère correctement exécuté et des secrets de session ensuite effacés. Cette confidentialité persistante ne protège toutefois pas une nouvelle session établie avec un imposteur accepté. Propriétés de TLS 1.3.
Faut-il acheter un autre certificat ?
Le critère décisif est la chaîne acceptée et sa bonne gestion. Un certificat payant ne corrige pas la liste de confiance d’une application distante. Les certificats gratuits peuvent convenir à un site professionnel : Let’s Encrypt propose notamment la validation de domaine, les noms multiples et les certificats génériques (wildcard). FAQ Let’s Encrypt.
Nuagerie inclut le SSL gratuit avec ses services qui le nécessitent ou le prennent en charge. Des certificats commerciaux peuvent être étudiés sur soumission pour des exigences précises. Le guide Choisir un certificat SSL/TLS distingue ces besoins du traitement d’un incident.
Une aide adaptée à votre environnement
Vous ne savez pas si le sujet relève de votre hébergement, de vos postes ou d’une application ? Notre équipe peut vous aider à préciser le périmètre, les responsabilités et les prochaines vérifications. Une connexion fonctionnelle ou le nom d’un fournisseur ne suffit pas, à lui seul, à confirmer la protection de tout un environnement.
Pour un service existant, retrouvez nos coordonnées dans la page d’assistance. Pour organiser une revue de vos services, parlons de vos besoins. Préparez les domaines, les logiciels concernés et les messages observés ; n’envoyez pas de clé privée dans une demande ordinaire.