CA intermédiaire compromise : quand la confiance se brise

Voici une idée qui semble à contre-courant : les pires incidents touchant une autorité de certification ne sont pas ceux où un attaquant s'introduit. Le récent compromis de CA intermédiaire chez eMudhra en est la preuve : huit clés de CA intermédiaires pouvaient être récupérées à partir des certificats eux-mêmes, sans aucune intrusion, parce que la cérémonie de génération de clés de la CA a produit des clés privées si faibles que l'une d'elles valait littéralement le nombre 4. Personne n'a volé ces clés. Elles sont nées compromises. Et c'est un mode de défaillance plus effrayant que n'importe quelle fuite, parce qu'on ne peut pas le corriger en renouvelant des identifiants et en colmatant une brèche. La confiance elle-même était défectueuse dès le premier jour.

Si vous faites tourner quoi que ce soit qui établit des connexions TLS en dehors d'un navigateur — et vous le faites — ce sujet mérite votre attention. Les navigateurs ont été protégés en quelques jours. Le reste de l'écosystème, les appels curl de vos tâches cron, les services Python qui épinglent certifi, les binaires Go avec leurs magasins racines intégrés, est encore en train de rattraper son retard. Je vais détailler ce qui s'est réellement passé, pourquoi une compromission d'intermédiaire est catégoriquement pire qu'une compromission de feuille, et ce que la remédiation inégale nous apprend sur l'état de la révocation sur l'internet moderne.

Ce qui a réellement mal tourné chez eMudhra

Selon l'évaluation préliminaire de la CA elle-même, publiée dans le suivi d'incidents de Mozilla, l'histoire est presque douloureusement banale. Un script de cérémonie de génération de clés — le processus contrôlé et audité par lequel une CA crée ses clés les plus sensibles — a été modifié avec une dérogation approuvée pour tester une procédure d'enveloppement et de désenveloppement de clé en vue d'un export. Un défaut dans ce code modifié a conduit à la génération d'un second jeu de clés ECC sur le HSM, et ces clés étaient faibles. Pas faibles au sens d'une « entropie réduite ». Faibles au sens où on peut les récupérer trivialement à partir du certificat public.

Réfléchissez à ce que cela signifie. Une clé privée ECC est censée être un nombre aléatoire de 256 bits. La sécurité de tout le schéma repose sur le problème du logarithme discret : étant donnée la clé publique, retrouver le scalaire privé doit être calculatoirement infaisable. Mais si votre scalaire « aléatoire » tient sur un seul octet, la clé publique n'est que le point générateur multiplié par cet octet, et n'importe qui peut tester les 256 possibilités en quelques microsecondes sur un ordinateur portable. L'une des huit clés valait apparemment l'entier 4. Ce n'est pas un compromis au sens traditionnel : c'est un certificat qui n'a jamais été réellement sécurisé, émis sous une racine approuvée par Mozilla, Microsoft, Apple et Chrome.

Le chercheur qui a signalé le problème, identifié comme Wayne, a prouvé la possession en signant un message avec chacune des huit clés privées et en soumettant les signatures aux programmes racines. N'importe qui pouvait vérifier la preuve avec quelques commandes OpenSSL : extraire la clé publique de chaque certificat intermédiaire, puis vérifier que la signature du message s'y rattache. C'est là le côté élégant et terrifiant de la preuve cryptographique de possession : aucune ambiguïté, aucun brouillard de communication du type « nous prenons la sécurité au sérieux ». Le calcul est juste ou il ne l'est pas. Il l'était.

Pourquoi une compromission de CA intermédiaire est pire que celle d'une feuille

Quand la clé privée d'un certificat feuille fuite — disons que votre clé pour api.example.com se retrouve dans un dépôt GitHub public — le rayon d'impact se limite à un nom d'hôte, peut-être quelques-uns si c'est un joker. Vous révoquez le certificat, en émettez un nouveau et passez à autre chose. Pénible, mais pas existentiel.

Une clé de CA intermédiaire est une tout autre bête. Le Web PKI fonctionne comme une chaîne de signatures : une CA racine (gardée hors ligne, protégée comme du matériel nucléaire) signe des intermédiaires, et ceux-ci signent les certificats feuilles que les serveurs présentent réellement. Quiconque détient la clé privée d'un intermédiaire est cette CA, à tous les égards cryptographiques. Il peut émettre un certificat valide pour google.com, pour votre banque, pour le domaine de votre SSO interne — et chaque client qui fait confiance à la chaîne l'acceptera sans broncher. Il n'y a ni limite de débit, ni autorité centrale à appeler, ni moyen de distinguer une signature frauduleuse mais valide d'une signature légitime.

L'incident eMudhra a multiplié cela par huit intermédiaires, certains contre-signés via des racines Sectigo, s'intégrant dans des magasins de confiance livrés sur des milliards d'appareils. Pendant environ un an et demi — de la création des certificats défectueux jusqu'à leur divulgation — tout client qui faisait confiance à ces intermédiaires et n'appliquait pas la Certificate Transparency pouvait être usurpé par quiconque prenait la peine de récupérer les clés. C'est cette fenêtre. Nous ne savons pas si quelqu'un l'a exploitée, et sans une détection chanceuse dans un journal CT ou une attaque observée, nous ne le saurons peut-être jamais.

C'est pourquoi les programmes racines traitent les incidents d'intermédiaires avec une gravité que les incidents de feuilles n'ont jamais. Défaire la confiance dans un intermédiaire signifie que chaque certificat qu'il a jamais émis devient invalide — des milliers de sites web tombant en même temps. L'affaire Symantec, qui s'est déroulée sur plusieurs années, est l'exemple canonique de la douleur d'une remédiation complète quand les opérations d'une CA sont jugées non fiables. Le système fonctionne, mais il fonctionne comme une amputation, pas comme une chirurgie.

Certificate Transparency, le héros par accident

Voici la partie de l'histoire qui mérite davantage d'attention : Chrome, Safari, Firefox et Edge ont sans doute été protégés avant que quiconque sache qu'il y avait un problème. Pas grâce à la révocation, mais grâce à la Certificate Transparency.

Les navigateurs qui appliquent CT exigent que chaque certificat publiquement approuvé qu'ils acceptent soit inscrit dans des journaux CT publics et en ajout seul. Les intermédiaires eMudhra compromis n'ont aucune entrée dans les journaux CT pour la période concernée, ce qui signifie que tout certificat feuille qu'un attaquant aurait forgé avec ces clés aurait été rejeté par les clients appliquant CT, car il serait arrivé sans horodatages de certificat signés valides. La fraude aurait dû être publiée pour être crue, et la publier l'aurait exposée immédiatement.

CT a été conçue pour détecter après coup les mauvaises émissions, afin de rendre les certificats frauduleux repérables. Dans cet incident, elle a joué un rôle de contrôle préventif : elle a rendu les clés compromises presque inutiles contre la population des navigateurs, qui constitue la cible à plus forte valeur pour une interception de masse. C'est une histoire vraiment positive pour une infrastructure à laquelle la plupart des ingénieurs ne pensent jamais.

Mais, et c'est ici que je reconnais les limites de mon optimisme, l'application de CT est essentiellement un luxe de navigateur. La grande majorité des clients TLS sur internet ne vérifient pas les SCT. Votre appel curl ne le fait pas. Votre appel Python requests non plus. La flotte d'objets connectés qui remonte vers le cloud d'un fabricant non plus. Pour tous ceux-là, seule protection : que les données de révocation atteignent le magasin de confiance à temps, et c'est là que l'histoire devient moche.

L'écart de révocation : navigateurs contre tout le reste

Les éditeurs de navigateurs ont bien géré la situation, et méritent des éloges pour une infrastructure construite il y a une dizaine d'années. Mozilla livre OneCRL depuis plus de dix ans, un mécanisme push pour défaire la confiance dans des certificats intermédiaires et racines, et il a remédié à cet incident pour les utilisateurs de Firefox en quelques heures, sans mise à jour du navigateur. Les CRLSets de Chrome et les mécanismes équivalents d'Apple ont fait de même sur leurs plateformes en quelques jours. La CA a révoqué les intermédiaires. Du point de vue de l'utilisateur de navigateur, cet incident était terminé presque avant d'avoir commencé.

Regardons maintenant le monde hors navigateur. La liste des correctifs ressemble à un inventaire de chaîne d'approvisionnement logicielle : paquets ca-certificates mis à jour pour Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo ; une nouvelle version de NSS ; un nouveau bundle de CA pour curl ; certifi pour Python ; rustls-webpki et webpki-roots pour Rust ; des versions correctives de Go ; des versions de correctifs Electron sur trois lignes de release ; le ca-bundle de Composer ; castore pour Elixir. Chacun de ces éléments est un artefact distinct, sur un rythme de publication distinct, consommé par un mécanisme de mise à jour distinct. Certains étaient encore en attente plusieurs jours après la divulgation.

Et il y a la catégorie qui me tient éveillé la nuit : les logiciels qui embarquent leur propre magasin de CA à l'intérieur du binaire. Un service Go lié statiquement et compilé l'an dernier transporte ses racines dans l'artefact compilé. Reconstruire et redéployer est la seule correction, car il n'existe aucun paquet système à mettre à jour. Multipliez cela par chaque image de conteneur de votre registre avec une couche /etc/ssl/certs figée, chaque application Electron sur chaque bureau, chaque image firmware de chaque appareil connecté, et vous voyez la forme du problème. Le magasin de confiance système est la partie facile. Nous avons déjà écrit sur la façon dont les appareils embarqués et OT transforment les incidents de sécurité en sagas de plusieurs années ; une CA compromise est exactement le type d'événement où ces appareils ne sont tout simplement jamais corrigés.

La longue traîne des magasins de confiance que personne ne possède

Cet incident contient un cas particulier qui mérite son propre paragraphe tant il illustre bien le problème : macOS. La plateforme d'Apple a rapidement bloqué les intermédiaires compromis au niveau du système. Mais le /usr/bin/curl intégré vérifie par rapport à /etc/ssl/cert.pem, un fichier qui n'a pas été mis à jour, et ne contrôle pas la révocation. Vous pouvez donc avoir un Mac entièrement à jour où Safari rejette un certificat forgé, tandis que le curl de cette même machine l'accepte sans problème. Deux décisions de confiance, une seule machine, des réponses opposées.

Cette fragmentation est la vraie leçon. On parle souvent du « Web PKI » comme s'il s'agissait d'un seul système. Il s'agit en réalité de dizaines de systèmes aux propriétés très différentes :

• Navigateurs : révocation par push (OneCRL, CRLSets), application de CT, mises à jour automatiques. Remédiation mesurée en heures à jours.
• Magasins de confiance des OS : mises à jour gérées par les paquets (ca-certificates, ca_root_nss). La remédiation dépend du rythme de publication de la distribution et de la question de savoir si la machine est un jour patchée.
• Écosystèmes de langages : certifi, webpki-roots, racines Go embarquées, magasin Mozilla intégré à Node. La remédiation implique de publier une version puis d'attendre les mises à jour de dépendances dans des milliers de projets.
• Artefacts compilés et images : binaires, conteneurs, firmwares. La remédiation signifie reconstruire et redéployer, ce qui, en pratique, laisse une longue traîne vulnérable s'étendant sur plusieurs années.
• IoT et embarqué : souvent aucune voie de mise à jour du tout. Exposition effectivement permanente.

Les navigateurs ont passé une décennie à investir précisément dans ce scénario. Presque personne d'autre ne l'a fait. Un commentaire en amont côté Mozilla l'a formulé sans détour : en dehors de l'écosystème des navigateurs, il y a eu peu ou pas d'investissement dans la révocation, et pour ces clients, ce type d'incident est un problème massif. Cela correspond à tout ce que j'ai observé en gérant des infrastructures. Si vous avez déjà eu affaire aux angles morts de la journalisation des événements d'authentification dans le cloud, vous reconnaîtrez le schéma : le chemin critique est bien instrumenté, et la longue traîne est une pièce plongée dans le noir.

Comment vérifier si vos clients sont encore vulnérables

La théorie mise à part, vous devriez réellement tester votre parc, et le bon côté de TLS est qu'on peut le tester empiriquement. Des membres de la communauté ont mis en place des hôtes présentant des certificats signés par les intermédiaires compromis ; si votre client se connecte sans erreur de certificat, c'est qu'il leur fait toujours confiance. Le schéma général pour tester curl ou n'importe quel outil en ligne de commande ressemble à ceci :

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

Lancez-le depuis chaque contexte qui compte : vos postes de développement, vos runners CI, les images de base de vos conteneurs, vos flottes de serveurs. Les réponses diffèrent d'un endroit à l'autre, et ces différences sont justement le propos. Pour un inventaire rapide de ce qu'il faut mettre à jour :

• Services Go : reconstruisez avec Go 1.27.3 ou 1.26.10 ou plus récent, car les racines sont compilées à l'intérieur.
• Python : certifi 2026.10.19 ou plus récent (vérifiez aussi les versions de pip et uv, qui embarquent leurs propres copies).
• Rust : rustls-webpki 0.103.16 et webpki-roots / webpki-root-certs 1.0.10.
• Node.js et Electron : versions en attente ou correctives par ligne de release ; vérifiez chaque artefact livré.
• Magasins système : les paquets ca-certificates mis à jour sont disponibles pour Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo ; le ca_root_nss de FreeBSD était en attente au moment de la rédaction.

Si vous ne pouvez pas attendre un paquet, la plupart des distributions Linux vous permettent de révoquer manuellement les racines concernées. Sur Debian et Ubuntu, il suffit de marquer les certificats avec un préfixe ! dans /etc/ca-certificates.conf puis d'exécuter update-ca-certificates ; sur la famille Fedora et RHEL, vous extrayez les racines dans /etc/pki/ca-trust/source/blocklist/ et exécutez update-ca-trust. NixOS propose une option déclarative propre :

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

Remarquez ce que vous révoquez réellement avec ces contournements : les racines auxquelles ces intermédiaires sont rattachés. C'est la réalité brutale de la remédiation PKI. La plupart des outils de magasin de confiance n'ont pas de primitive « ne plus faire confiance à cet intermédiaire uniquement », donc vous mettez une racine sur liste noire et acceptez les dommages collatéraux sur des certificats sans rapport. C'est le bon compromis en urgence, mais c'est bien un compromis.

Là où mon affirmation à contre-courant s'effondre

J'ai commencé en affirmant que les échecs de génération de clés auto-infligés sont pires que les fuites. Soyons honnêtes sur les limites de cette idée. Une fuite traditionnelle, pensez à DigiNotar, suppose au moins que la CA opérait de façon compétente jusqu'à ce qu'un attaquant la dépasse, et des CA compétentes, c'est précisément sur quoi tout le système parie. Une cérémonie de clés qui émet la clé privée « 4 » signifie que les contrôles audités, les procédures HSM, les cases de conformité, rien de tout cela n'a détecté un défaut catastrophique dans l'opération la plus sensible qu'une CA réalise. Ce n'est pas un problème d'adversaire ; c'est un problème d'assurance, et l'assurance est tout le produit qu'une CA vend.

Là où l'affirmation échoue vraiment : les brèches sont plus difficiles à défendre et peuvent rester silencieuses plus longtemps. Un attaquant qui vole une clé d'intermédiaire, avec prudence, pourrait s'en servir avec parcimonie pour une interception ciblée et ne jamais toucher un client qui applique CT. Les clés faibles, en revanche, sont découvrables par quiconque scanne les certificats publics, et c'est exactement ainsi que celle-ci a été mise au jour. On peut soutenir que « catastrophique mais évident » vaut mieux que « subtil mais ciblé ». Je n'y adhère pas totalement, mais je ne peux pas non plus l'écarter. La vérité, c'est que les deux modes de défaillance aboutissent au même endroit : un intermédiaire qu'il faut révoquer, et une longue traîne de clients qui ne recevront le message que dans des mois.

Ce que vous devriez réellement faire

Vous ne pouvez pas réparer le Web PKI. Vous pouvez en revanche réduire votre exposition à sa prochaine défaillance :

• Testez, ne présumez pas. Sondez vos clients avec des hôtes qui présentent les chaînes compromises. Cela prend un après-midi et vous surprendra.
• Reconstruisez les artefacts compilés. Les binaires Go et les images de conteneurs transportent leurs magasins de confiance avec eux. « Nous avons corrigé l'image de base » ne veut rien dire tant que vous n'avez pas redéployé.
• Inventoriez vos magasins de confiance. Vous ne pouvez pas corriger ce que vous n'avez pas énuméré. Comptez les copies de certifi, les bundles embarqués et les applications Electron comme si cela comptait, car c'est le cas.
• Privilégiez les magasins de confiance système quand c'est possible. Chaque bundle embarqué est un correctif que vous oublierez de livrer. Centraliser sur le magasin de l'OS ne supprime pas le problème, mais vous offre un seul point de contrôle.
• Surveillez l'écosystème CT et de révocation. Des projets visent à apporter une révocation de qualité navigateur aux clients hors navigateur ; ils méritent votre soutien, et cet incident est le meilleur argument qu'ils obtiendront jamais pour être financés.
• Traitez les incidents de CA comme des incidents de sécurité. Ils doivent alerter quelqu'un, déclencher un inventaire et produire un compte rendu écrit, comme pour un identifiant divulgué. Parce que c'est exactement ce qu'ils sont.

Le constat inconfortable : le frein d'urgence du Web PKI fonctionne à merveille exactement sur les clients qui en avaient le moins besoin, parce que CT les couvrait déjà. Ceux qui en avaient réellement besoin, sans écran, embarqués, enfouis dans des bundles, oubliés, n'en disposent presque jamais. La prochaine compromission d'une CA intermédiaire n'est pas une question de si, mais de quand. La seule variable sous votre contrôle est de savoir si votre propre parc s'en apercevra.