The eMudhra SSL certificate trust removal requires operators to replace any certificate chain ending at emSign ECC Root CA – G3. Google scheduled Chrome’s removal for the morning of October 27, 2026, Pacific time, while Apple began blocking the root on October 23, 2026. Check every public TLS endpoint, install a chain under a trusted root, and test it externally.
Pourquoi Chrome supprime-t-il la confiance accordée à la racine eMudhra ?
Chrome supprime la confiance accordée à emSign ECC Root CA – G3, car cette racine a signé une hiérarchie contenant des clés d’autorité de certification intermédiaires eMudhra compromises. Google a programmé la suppression de cette racine du Chrome Root Store pour le 27 octobre 2026, après avoir bloqué les clés intermédiaires concernées via CRLSet le 17 octobre 2026.
La suppression de la confiance accordée au certificat SSL eMudhra fait suite à un rapport indiquant que les clés privées de huit certificats d’autorités de certification intermédiaires pouvaient être récupérées, car elles présentaient un niveau d’aléa insuffisant. Selon l’avis de sécurité de Google d’octobre 2026, six certificats intermédiaires étaient utilisés pour TLS et deux pour la signature de code.
Une autorité de certification intermédiaire est une AC qui signe des certificats situés sous une racine approuvée, créant un chemin vérifiable entre le certificat d’un site web et la racine enregistrée par un navigateur ou un système d’exploitation. La possession de l’une des six clés intermédiaires TLS aurait pu permettre à un attaquant de créer des certificats apparemment valides pour des sites web arbitraires sur des clients qui n’avaient pas bloqué la clé.
Google a déclaré en octobre 2026 qu’aucun certificat TLS d’entité finale approuvé publiquement n’avait été émis à partir de ces six certificats intermédiaires compromis avant le blocage. Le danger résidait dans la capacité de signature exposée, et non dans l’existence avérée d’un grand nombre de faux certificats de sites web.
eMudhra a révoqué les huit certificats intermédiaires en environ 14 heures, entre le 17 et le 18 octobre 2026. Les clés faibles appartenaient à des AC intermédiaires et non à la racine elle-même, mais Google a supprimé emSign ECC Root CA – G3 par mesure de précaution, car cette racine constituait l’ancrage de la hiérarchie compromise.
Les 30 800 certificats concernés sont-ils tous falsifiés ?
Non. Les quelque 30 800 certificats ou précertificats non expirés identifiés dans Certificate Transparency le 21 octobre 2026 étaient des certificats légitimes remontant jusqu’à emSign ECC Root CA – G3. L’analyse de l’incident par Mozilla n’a pas classé ces certificats comme des falsifications ; la perte de confiance envers la racine a rendu leur chemin de confiance problématique sur le plan opérationnel.
Cette distinction est importante. Une clé de signature compromise permet de falsifier des certificats, tandis qu’un certificat légitime peut devenir inutilisable simplement parce que les navigateurs cessent de faire confiance à une racine située ailleurs dans sa chaîne. Considérer chaque certificat concerné comme malveillant exagère l’incident et peut détourner l’attention du travail de remplacement.
| Chemin ou groupe de certificats | Nombre rapporté | Signification du nombre |
|---|---|---|
| InCommon Intermediate CA – OVG3C | 23,806 | Certificats légitimes associés à une AC subordonnée d’Internet2/InCommon |
| InCommon Intermediate CA – DVG3C | 6,985 | Certificats légitimes associés à une AC subordonnée d’Internet2/InCommon |
| Deux certificats intermédiaires InCommon combinés | 30,791 | Certificats nécessitant une migration depuis le chemin de la racine concernée |
| Certificats intermédiaires exploités par eMudhra | 18 | Certificats supplémentaires signalés lors de l’examen de Certificate Transparency |
| Population concernée arrondie | Environ 30 800 | Certificats ou précertificats non expirés remontant jusqu’à la racine désapprouvée |
Les deux sous-totaux affichés, 30 791 et 18, donnent 30 809. Ce total dépasse le chiffre arrondi de « environ 30 800 » indiqué dans le titre ; vous ne devez donc pas transformer les valeurs publiées en un total faussement exact. La discussion de Mozilla d’octobre 2026 a également rapporté l’estimation d’eMudhra selon laquelle environ 97% de quelque 30 000 certificats avaient été émis via ACME.
Cette concentration explique pourquoi les réseaux universitaires et de recherche utilisant Internet2/InCommon méritent une attention particulière. Un grand nombre de certificats relevant de deux AC subordonnées ne signifie pas que des milliers de compromissions indépendantes se sont produites. Cela signifie qu’une seule décision de confiance peut avoir de vastes répercussions en aval.
Comment vérifier si une chaîne de certificats eMudhra est concernée ?
Vérifiez une chaîne de certificats eMudhra en examinant ce que le serveur actif envoie, en recherchant « emSign » ou « eMudhra » dans le chemin de l’émetteur et en identifiant l’ancre de confiance terminale. Une chaîne se terminant par emSign ECC Root CA – G3 est concernée par la perte de confiance d’octobre 2026, même lorsque le certificat feuille n’a pas encore expiré.
Les recommandations de SSL.com pour octobre 2026 préconisent d’interroger le point de terminaison avec openssl s_client -connect hostname:443 -servername hostname -showcerts. Remplacez les deux occurrences de hostname par le véritable nom DNS. L’indication du nom du serveur est importante, car une adresse IP partagée peut renvoyer un certificat par défaut lorsque -servername est omis.
Lisez les certificats renvoyés dans l’ordre et examinez chaque sujet et chaque émetteur. Ne vous contentez pas de vérifier le certificat feuille. La suppression de la confiance accordée au certificat SSL eMudhra concerne le chemin de certification ; un certificat de domaine d’apparence normale peut donc tout de même échouer lorsque le serveur fournit un certificat intermédiaire concerné ou que le client construit le chemin jusqu’à la racine supprimée.
One commonly missed pitfall is testing only the main website. Inventory API hostnames, authentication portals, CDN origins, mail services, load balancers, gateways, staging systems, container ingress points and vendor-managed endpoints. Operators responding to other urgent issues, such as an vulnérabilité GitLab activement exploitable, savent déjà que les services secondaires oubliés prolongent souvent le nettoyage d’un incident.
Comment remplacer un certificat concerné avant la perte de confiance ?
Remplacez un certificat concerné en obtenant un nouveau certificat feuille dont la chaîne remonte jusqu’à une hiérarchie actuellement approuvée, en installant la chaîne intermédiaire complète prévue et en la déployant sur chaque point de terminaison TLS. eMudhra a commencé à proposer des remplacements émis par Sectigo via CertiNext ou le support eMudhra le 22 octobre 2026.
La séquence de remédiation suivante, pour octobre 2026, couvre les points de défaillance les plus susceptibles de laisser un nom d’hôte inutilisable :
- Recensez chaque site web, API, CDN, équilibreur de charge, serveur de messagerie, passerelle, point d’entrée de conteneur et autre point de terminaison TLS public.
- Inspectez chaque chemin actif et signalez les chaînes contenant eMudhra, emSign ou emSign ECC Root CA – G3.
- Demandez un certificat de remplacement auprès d’une AC dont la chaîne reste approuvée par les navigateurs, systèmes d’exploitation et environnements d’exécution applicatifs requis.
- Installez le nouveau certificat feuille et le paquet intermédiaire complet sur chaque couche de terminaison, y compris les périphéries gérées par les fournisseurs.
- Forcez ou reconfigurez l’émission ACME lorsque la date de renouvellement normale tombe après la date limite de perte de confiance d’octobre 2026.
- Testez à nouveau chaque nom d’hôte depuis l’extérieur de votre réseau et confirmez la chaîne reçue par les clients actuels.
L’automatisation ACME n’est pas une preuve de sécurité. La discussion de Mozilla sur l’incident d’octobre 2026 a explicitement averti les opérateurs de ne pas supposer qu’un calendrier de renouvellement normal remplacerait le chemin concerné à temps. Forcez le renouvellement si nécessaire, puis inspectez la chaîne obtenue au lieu de vous fier à un journal de tâche indiquant une réussite.
Un calcul concret montre le risque : un certificat de 90 jours auquel il reste 45 jours, avec un client ACME configuré pour renouveler lorsqu’il reste 30 jours, ne tentera pas de renouvellement de routine avant 15 jours supplémentaires. Si la défiance envers la racine intervient aujourd’hui, l’automatisation fonctionne exactement comme prévu, tandis que le site échoue toujours aujourd’hui.
Honnêtement, remplacer uniquement le serveur web public est un raccourci peu judicieux. Le déploiement de certificats ressemble à un travail plus vaste de réponse d’urgence : la rigueur de l’inventaire utilisée pour les incidents impliquant des serveurs de sauvegarde non corrigés s’applique également aux points de terminaison TLS dissimulés derrière des proxys et des passerelles.
Comment pouvez-vous vérifier que le remplacement fonctionne réellement ?
Vérifiez le remplacement eMudhra en testant chaque nom d’hôte public depuis un réseau externe, en confirmant que le serveur envoie les intermédiaires prévus et en vous connectant avec la version actuelle de Chrome et d’autres clients majeurs. Les recommandations de Google d’octobre 2026 demandent également de mettre à jour les environnements d’exécution, les images de base et les applications qui gèrent des magasins de certificats indépendants.
Commencez par une autre requête openssl s_client contre le point de terminaison actif, et non contre un fichier de certificat local. Confirmez que l’ancien chemin eMudhra est absent et que le serveur fournit les certificats intermédiaires nécessaires. Utilisez ensuite les versions actuelles des navigateurs et des systèmes d’exploitation représentatifs depuis l’extérieur du réseau de l’entreprise.
Apple adds an awkward edge case. Apple reported on October 23, 2026, that some macOS command-line tools, including curl, git, Python, Ruby, Perl and OpenSSL, could continue using /etc/ssl/cert.pem jusqu’à une future mise à jour logicielle, indépendamment du blocage appliqué par la plateforme Apple. Une requête curl réussie ne prouve donc pas nécessairement que Safari ou un autre client utilisant le magasin de confiance de la plateforme acceptera la même chaîne.
Apple a commencé à bloquer 12 certificats représentant les six clés intermédiaires TLS des chemins eMudhra et Sectigo le 19 octobre 2026, puis a bloqué emSign ECC Root CA – G3 le 23 octobre 2026. Des résultats divergents selon les applications sont plausibles, car les navigateurs, les systèmes d’exploitation et les environnements d’exécution intégrés peuvent consulter des magasins de confiance différents.
Consignez pour chaque résultat le nom d’hôte, la chaîne observée, la version du client, le système d’exploitation et l’heure du test. Ces éléments sont bien plus utiles qu’une capture d’écran indiquant « ça fonctionne chez moi », en particulier lorsqu’une équipe de sécurité suit également des risques de confiance propres aux navigateurs, tels que les défaillances de confiance des extensions Chrome.
Que signifie le retrait d’eMudhra du marché mondial des certificats SSL/TLS ?
Le conseil d’administration d’eMudhra a décidé le 22 octobre 2026 de se retirer du marché mondial des certificats SSL/TLS. eMudhra a indiqué que ses racines G1 RSA continueraient de fonctionner pendant la migration, tandis que les services de révocation et d’état des certificats resteraient disponibles jusqu’à l’expiration des certificats émis ou jusqu’à leur remplacement par les clients.
L’entreprise a indiqué que le SSL/TLS mondial représentait environ 1% de son chiffre d’affaires mondial en 2026. Le 26 octobre 2026, eMudhra a reconnu que sa propre erreur de script avait provoqué l’incident lié aux clés faibles, s’est excusée et a déclaré qu’un examen mené par un expert indépendant ainsi qu’un rapport complet d’analyse des causes racines dans la Common CA Database suivraient.
Selon le récit d’eMudhra, les huit autorités de certification intermédiaires ont été créées lors d’une cérémonie de génération de clés le 30 avril 2025. Une erreur de script wrap/unwrap a créé un second ensemble de clés faibles, qui a été utilisé par erreur pour les demandes de signature de certificats.
Le retrait de la confiance accordée aux certificats SSL d’eMudhra ne signifie pas automatiquement que chaque certificat G1 RSA échoue le 27 octobre 2026. La confiance dépend du chemin exact construit par le client. Néanmoins, le retrait d’eMudhra du marché rend une migration planifiée plus judicieuse que d’attendre le dernier jour de validité de chaque certificat.
FAQ sur l’incident lié aux certificats eMudhra
La clé privée racine d’eMudhra a-t-elle été compromise ?
La clé privée de emSign ECC Root CA – G3 n’a pas été signalée comme compromise en octobre 2026. Les clés récupérables appartenaient à huit autorités de certification intermédiaires, tandis que la racine a été supprimée parce qu’elle ancravait la hiérarchie concernée.
Un certificat eMudhra non expiré affichera-t-il toujours un avertissement ?
Un certificat non expiré peut afficher un avertissement lorsque sa chaîne se termine par emSign ECC Root CA – G3 après la suppression de la confiance par un client. Les dates de validité du certificat ne prévalent pas sur la décision du magasin de racines du navigateur.
La révocation des certificats intermédiaires corrige-t-elle les sites web existants?
La révocation des huit certificats intermédiaires le 18 octobre 2026 a réduit le risque d’utilisation abusive, mais n’a pas permis de migrer les sites légitimes hors de la racine non approuvée. Les opérateurs concernés doivent encore adopter une chaîne de remplacement sous une hiérarchie de confiance.
Un test OpenSSL réussi peut-il prouver que Chrome fonctionnera ?
La réussite d’OpenSSL ne garantit pas l’acceptation par Chrome, car OpenSSL et Chrome peuvent utiliser des magasins de certificats de confiance et des règles de construction de chaîne différents. Testez le nom d’hôte en production avec la version actuelle de Chrome après avoir vérifié la chaîne de certificats en ligne de commande.