Compromission des clés de l'AC eMudhra : ce que les entreprises doivent vérifier et corriger maintenant

Le samedi 17 octobre 2026, un chercheur en sécurité a signalé que huit autorités de certification intermédiaires exploitées par eMudhra, une autorité de certification indienne, avaient des clés privées que n'importe qui pouvait retrouver à partir des certificats publics. Chacune de ces clés était un nombre inférieur à 256. L'une d'elles était le nombre 4. Six des huit pouvaient émettre des certificats TLS reconnus par Apple, Google, Microsoft et Mozilla ; les deux autres pouvaient signer des logiciels Windows.

Chrome a bloqué les six clés TLS une heure et quarante minutes après le signalement, et Firefox le soir même. Pour les internautes, le danger était écarté dès le samedi soir.

Pas pour tout le reste. Les serveurs, les conteneurs, les applications Java, les scripts Python, les intégrations de paiement et les appareils connectés vérifient les certificats à l'aide de leur propre copie de la liste des autorités de confiance, et la plupart de ces copies ne changent que lorsque quelqu'un installe une mise à jour. D'ici là, un certificat signé avec l'une de ces clés, pour n'importe quel domaine, passe pour authentique, et les clés sont publiques depuis le 20 octobre.

La même semaine, GoDaddy a commencé à révoquer 404 607 certificats parce que les informations de politique qu'ils contenaient ne correspondaient pas à ses propres documents publiés. Ses clients ont dû télécharger et installer eux-mêmes les certificats de remplacement.

Ce guide s'adresse à ceux qui doivent répondre à la question « sommes-nous concernés ? » : responsables informatiques et d'exploitation, CTO, et fondateurs dont l'activité repose sur un site web, une API ou un produit connecté. Il décrit ce qui s'est passé, d'après les rapports d'incident publiés par Mozilla, Google, eMudhra, GoDaddy et les éditeurs de logiciels ; ce qu'il faut vérifier aujourd'hui ; ce qu'il faut mettre à jour cette semaine ; et ce qu'il faut mettre en place pour que le prochain incident de ce type devienne une routine. Tout ce qui suit est à jour au 22 octobre 2026, et l'incident n'est pas encore clos.

Ce qui s'est passé

eMudhra a créé les huit intermédiaires lors d'une cérémonie des clés le 30 avril 2025. Son récit, publié le 19 octobre dans le ticket d'incident de Mozilla : un test d'une étape de chiffrement et de déchiffrement de clé (key wrap et unwrap), approuvé comme dérogation à sa procédure habituelle, comportait une faille qui a créé un second jeu de clés, faibles, dans le module matériel de sécurité (HSM), à côté des clés prévues. Les libellés se ressemblaient, les clés faibles ont été utilisées par erreur pour créer les demandes de certificat, et la racine d'eMudhra les a signées. Les mêmes demandes ont été envoyées à Sectigo, qui a émis pour les huit, le 14 mai 2025, des certificats croisés depuis sa racine AAA Certificate Services. eMudhra indique n'avoir « pas encore confirmé la cause profonde exacte ».

Mozilla a décrit le résultat : « Les clés privées P384 sont des entiers choisis au hasard entre 1 et l'ordre du groupe. Les 8 clés concernées utilisaient toutes des entiers inférieurs à 256. » Mozilla a reçu le signalement à 20 h 06 UTC et a retrouvé les clés de son côté à 21 h 48, « sans rien savoir de la méthode utilisée par l'auteur du signalement initial ». Le chercheur dit les avoir trouvées avec paranoid_crypto, la bibliothèque open source de Google, utilisée « telle quelle ». Les clés faibles faisaient partie de chaînes reconnues publiquement depuis près de 18 mois.

Les huit certificats :

Chaque clé figure dans deux certificats. L'un a été émis par emSign Root TLS CA - G3 ou emSign Root CS CA - G3, les racines d'eMudhra, qui remontent à emSign ECC Root CA - G3 ; l'autre est le certificat croisé de Sectigo émis depuis AAA Certificate Services. Ce second chemin compte, car certains magasins de confiance (trust stores) qui n'ont jamais contenu de racine eMudhra font toujours confiance à cette ancienne racine Sectigo.

Y a-t-il eu des attaques ?

Personne n'a signalé d'utilisation malveillante, et pour les navigateurs il y a une bonne raison de penser qu'il n'y en a pas eu. Chrome, comme les autres clients qui appliquent Certificate Transparency (CT), n'accepte un certificat que s'il a été enregistré dans les journaux CT publics. Google : aucun certificat TLS remontant à ces six intermédiaires n'avait été journalisé avant son blocage, si bien qu'« aucun certificat frauduleux émis par ces AC n'aurait pu être utilisé contre des clients qui appliquent CT ».

Hors du navigateur, le tableau est différent. La page d'incident de Mozilla : « de nombreux clients extérieurs à l'écosystème des navigateurs n'appliquent pas Certificate Transparency. Nous ne savons pas si des attaquants ont exploité la génération de clés défaillante pour cibler ces clients. » Cette fenêtre s'est ouverte au printemps 2025 et ne se referme, pour chaque client, qu'une fois celui-ci mis à jour. eMudhra dit n'avoir connaissance d'aucun élément indiquant que les clés aient été retrouvées avant la divulgation, et Cloudflare indique que son examen n'a révélé aucune exploitation active sur ses services.

Maintenant que les clés sont publiques, falsifier un certificat ne demande aucune compétence. La page d'incident de Mozilla répertorie des serveurs de test qui présentent des certificats émis avec les clés compromises, afin que chacun puisse y confronter ses clients (les commandes figurent plus bas).

Ce que permet un certificat falsifié : quiconque peut intercepter le trafic entre votre logiciel et un service qu'il appelle (sur un réseau partagé, via un routeur compromis ou une réponse DNS empoisonnée) peut se faire passer pour ce service, lire ce que votre logiciel envoie, clés d'API et données personnelles comprises, et modifier ce qu'il reçoit. Un logiciel signé avec l'une des deux clés de signature de code aurait passé la vérification de signature de Windows jusqu'à ce que le blocage de Microsoft atteigne la machine.

Qui est concerné

Il y a trois problèmes distincts, et une même entreprise peut les avoir tous les trois.

1. Les logiciels qui font encore confiance aux clés compromises

Presque toutes les entreprises sont concernées par celui-ci : tout programme qui effectue des appels HTTPS, dont le magasin de confiance contient encore emSign ECC Root CA - G3 ou AAA Certificate Services, et qui n'a pas reçu de blocage pour les huit clés. Les endroits typiques :

• Les serveurs Linux et les images de conteneur construites avant le 20 ou le 21 octobre. Une Debian 12 non corrigée, par exemple, fait confiance aux deux chaînes.
• Les environnements d'exécution qui embarquent leur propre liste : Node.js, certifi pour Python, le cacerts de Java, le bundle de Composer pour PHP, webpki-roots pour Rust.
• Les outils en ligne de commande de macOS. La page d'incident de Mozilla indique que les curl, git, python3, perl, ruby et openssl intégrés au système vérifient les certificats à l'aide de /etc/ssl/cert.pem sans contrôler la révocation, et qu'Apple n'a pas mis à jour ce fichier.
• Les machines Windows qui ne reçoivent pas les mises à jour automatiques de la liste des certificats non autorisés de Microsoft, généralement parce qu'une stratégie de groupe les désactive ou que le réseau est hors ligne.
• Les appliances, les appareils et les logiciels tiers qui intègrent leur propre fichier d'AC, comme les répartiteurs de charge, les passerelles VPN, les SDK et les contrôleurs embarqués.

Chaque environnement d'exécution doit être vérifié séparément. Lors d'un test que nous avons mené le 22 octobre, une machine Debian 12 non corrigée avec Node.js 24.18 acceptait la chaîne qui se termine à la racine d'eMudhra et rejetait celle qui se termine à la racine de Sectigo, tandis que Python, sur la même machine, acceptait les deux.

2. Les entreprises dont les propres certificats remontent à la racine retirée

Mozilla et les distributions Linux ont retiré emSign ECC Root CA - G3, et Chrome suivra le 27 octobre. Les certificats valides placés sous cette racine cessent de fonctionner dans chaque client au fur et à mesure de sa mise à jour. La consigne de Google : les opérateurs de sites web qui ont de tels certificats « doivent immédiatement se procurer et installer un nouveau certificat TLS provenant d'une autre hiérarchie PKI incluse dans le Chrome Root Store ».

Le 21 octobre, Chrome a dénombré dans CT environ 30 800 certificats non expirés sous cette racine. 30 791 d'entre eux provenaient de deux intermédiaires d'InCommon, le service de certificats qu'Internet2 exploite pour les universités et les établissements de recherche américains, et qui émet des certificats ECC via CERTInext, la plateforme d'eMudhra. Les intermédiaires d'eMudhra elle-même en avaient émis 18. eMudhra indique qu'environ 30 000 certificats doivent être migrés, dont environ 97 % émis via ACME, et qu'elle émet des certificats de remplacement depuis une autre hiérarchie.

Si votre site est derrière Cloudflare en mode Full (strict) et que le serveur d'origine présente un certificat sous cette racine, Cloudflare indique que le retrait de confiance « provoquerait des pannes » et demande à ses clients : « Vérifiez vos certificats d'origine personnalisés et vos configurations de serveur ».

Les certificats RSA émis sous l'autre racine d'eMudhra, emSign Root CA - G1, ne sont pas concernés à ce jour. Mozilla indique ne pas retirer cette racine « pour le moment » ; Chrome « examine de près le maintien des autres certificats d'AC d'eMudhra ». Si vous dépendez de certificats eMudhra ou CERTInext, quels qu'ils soient, prévoyez dès maintenant une seconde autorité de certification.

3. Les clients de GoDaddy

Le cas de GoDaddy n'a rien à voir avec eMudhra, mais il est survenu la même semaine et a touché beaucoup plus de sites. Le 15 octobre, GoDaddy a signalé à Mozilla que des certificats de ses hiérarchies GoDaddy et Starfield contenaient des informations de politique de certification (OID de politique et liens vers la CPS) qui ne correspondaient pas aux profils de sa propre CP/CPS, le document dans lequel une autorité de certification indique ce qu'elle émet. Ce n'est pas une faille de sécurité des certificats. Selon les Baseline Requirements, les règles que suit toute autorité de certification publique, c'est néanmoins un motif de révocation dans un délai de cinq jours.

Au total, 404 607 certificats étaient concernés, dont 396 055 à validation de domaine. GoDaddy en avait révoqué 170 566 à l'échéance du 18 octobre, 23 h 45 UTC, et 227 422 au lendemain matin ; son avis aux clients indique que les autres ont été révoqués le 21 octobre. GoDaddy réémet les certificats, mais leur installation incombe au client : « les visiteurs de votre site web peuvent voir des avertissements de sécurité, et votre site peut devenir inaccessible jusqu'à l'installation d'un nouveau certificat. »

Ce qu'il faut vérifier aujourd'hui

1. Qu'envoient vos propres serveurs ? Pour chaque nom d'hôte public, listez les émetteurs de la chaîne qu'il présente :

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Une ligne qui mentionne eMudhra, emSign, l'une des autorités EM ... G3B ou G3C, ou InCommon Intermediate CA - DVG3C, OVG3C ou EVG3C signifie que le certificat doit être remplacé avant le 27 octobre. Si AAA Certificate Services apparaît seul, c'est normal, car de nombreuses chaînes Sectigo ordinaires l'incluent encore. Pour les services de messagerie et d'annuaire, ajoutez -starttls smtp (ou imap, ldap) et le bon port. Incluez les hôtes internes, les répartiteurs de charge et les serveurs d'origine derrière un CDN.

2. Quels certificats ont été émis pour vos domaines ? CT répertorie chaque certificat qu'une autorité de certification publique a émis pour vos noms, y compris ceux dont personne dans l'entreprise ne se souvient d'avoir passé commande :

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

La sortie montre aussi quelles autorités de certification votre entreprise utilise réellement, ce qui est le point de départ de l'inventaire décrit plus bas.

3. Vos clients font-ils confiance aux clés compromises ? Les serveurs de test de Mozilla présentent des certificats émis sous les clés compromises : une erreur de certificat est donc le bon résultat. Testez les deux familles : le premier hôte remonte à la racine d'eMudhra, le second à celle de Sectigo, et un même magasin de confiance peut échouer à l'un des tests et réussir l'autre.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl ne répond que pour curl. Lancez la même requête via la pile TLS propre à chaque application, dans l'environnement où l'application s'exécute :

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Les deux lignes Python ne font pas double emploi : urllib utilise le magasin du système d'exploitation, requests utilise certifi. Répétez chaque ligne avec l'hôte dv-g3b-aaa-emudhra. Pour Java, faites n'importe quel appel HTTPS vers les serveurs de test depuis la JVM concernée, et vérifiez si son magasin contient l'une ou l'autre racine (Java 9 ou ultérieur ; sous Java 8, utilisez -keystore $JAVA_HOME/jre/lib/security/cacerts) :

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

La présence d'une racine dans un magasin ne prouve pas à elle seule l'exposition, car Go, Node.js, Deno et rustls-webpki pour Rust bloquent désormais les huit clés quel que soit le contenu du magasin. Ce sont les serveurs de test qui tranchent.

4. Parcs Windows. Microsoft n'a rien publié sur l'incident, mais la liste des certificats non autorisés que Windows télécharge automatiquement bloque les huit clés depuis le 20 octobre. Les exceptions sont les machines sur lesquelles une stratégie de groupe désactive la mise à jour automatique des certificats racines, et les réseaux sans accès à Windows Update ; il faut alors leur fournir la liste par un autre moyen. certutil -verifyCTL Disallowed affiche la copie qu'une machine a en cache. La page d'incident de Mozilla propose un script pour les machines individuelles et précise qu'il n'est « pas recommandé pour les appareils gérés par une entreprise ».

5. Certificats GoDaddy. Vérifiez quel certificat chaque serveur présente réellement :

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Si l'émetteur est GoDaddy ou Starfield, comparez le numéro de série avec les certificats de votre compte GoDaddy. Là où GoDaddy affiche « Install your new certificate » (installez votre nouveau certificat), le serveur présente toujours le certificat révoqué.

Une règle s'applique à chaque étape : ne faites pas disparaître une erreur en désactivant la vérification des certificats. Cloudflare le dit ainsi : « Il est important de ne pas résoudre ces erreurs en désactivant la vérification. » Un client qui ne vérifie pas fait confiance à tous les certificats falsifiés, pas seulement à ceux-ci.

Ce qu'il faut mettre à jour cette semaine

Il existe deux types de correctif. Retirer les deux racines ferme tous les chemins pour un client qui utilise ce magasin, mais casse aussi les certificats valides placés sous ces racines. Bloquer les huit clés par le hachage de leur clé publique, comme le font Go, Node.js, Deno, Electron, rustls-webpki, Composer et Windows, bouche la faille sans rien casser d'autre. Là où votre plateforme propose la seconde méthode, préférez-la.

« Pas encore » signifie que rien n'avait été publié au 22 octobre. Vérifiez de nouveau avant de bâtir votre planning là-dessus.

Quatre pièges guettent les équipes :

• Les images de conteneur gardent l'ancienne liste. Une image construite avant le 20 ou le 21 octobre fait confiance aux clés jusqu'à ce qu'elle soit reconstruite sur une image de base à jour, et un nouveau pull du même tag ne sert à rien tant que l'image de base n'a pas été reconstruite. Reconstruisez, redéployez, et interrogez les éditeurs dont vous exécutez les images.
• Les processus gardent ce qu'ils ont chargé. Un programme lit son magasin de confiance au démarrage : redémarrez donc les services de longue durée après la mise à jour. Node.js ajoute que les sessions TLS ouvertes avant la mise à niveau puis reprises ne sont pas revérifiées.
• Les applications embarquent leurs propres fichiers d'AC. Les SDK et les applications livrent souvent leur propre cacert.pem ou ca-bundle.crt. Recherchez-les dans les dépôts et les images, par exemple avec find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, et attendez-vous à en trouver plusieurs : pip, notamment, embarque sa propre copie de certifi.
• Les appareils attendent leur fabricant. Demandez par écrit à chaque fabricant quel magasin de confiance le produit utilise et quand la mise à jour sera livrée. D'ici là, l'appareil fait confiance aux certificats falsifiés pour chaque service qu'il appelle : limitez donc ce qu'il peut atteindre.

Si vous retirez AAA Certificate Services à la main, comme le font Debian, Ubuntu ESM, Fedora et le contournement de Red Hat, testez ensuite les connexions vers les services qui ont des certificats Sectigo : certains serveurs anciens envoient encore une chaîne qui se termine à cette racine.

Ce qu'il faut mettre en place avant le prochain incident

Qu'une autorité de certification laisse passer des clés aussi faibles est rare. Les révocations massives, non. Voici les plus importantes de 2026 recensées dans le système de suivi de bugs de Mozilla :

Aucun de ces cinq cas n'était une défaillance de sécurité. Dans chacun, un certificat contredisait le document de l'autorité elle-même, et les Baseline Requirements (section 4.9.1.1) imposent malgré tout la révocation sous cinq jours. Lorsqu'une clé est compromise, ou que la validation de domaine n'est pas fiable, le délai est de 24 heures. Personne ne peut le prolonger pour vous. Lors de la révocation de 83 267 certificats par DigiCert en 2024, le Chrome Root Program a écrit qu'il « n'a pas le pouvoir d'accorder des exceptions » ; un client a obtenu une ordonnance de justice pour bloquer la révocation de ses certificats, et l'ordonnance a été levée quatre jours plus tard.

La façon dont les remplacements se sont déroulés en dit long. En juillet, HARICA a utilisé ACME Renewal Information (ARI) pour demander aux clients ACME de ses clients de renouveler en avance, et a réémis elle-même d'autres certificats ; lors de la plus importante de ses deux révocations, 87 % des noms concernés avaient été remplacés à l'échéance. GoDaddy, dont les clients téléchargent et installent eux-mêmes chaque certificat de remplacement, avait révoqué 42 % de ses certificats concernés à son échéance.

Le cycle de renouvellement raccourcit de toute façon :

• Depuis le 15 mars 2026, en vertu du ballot SC-081 du CA/Browser Forum, la durée des certificats TLS publics est limitée à 200 jours. La limite passe à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029, date à partir de laquelle une validation de domaine ne pourra être réutilisée que pendant 10 jours.
• Let's Encrypt passe par défaut à des certificats de 64 jours le 10 février 2027, puis de 45 jours un an plus tard.
• Les certificats TLS publics perdent l'authentification client. Let's Encrypt a cessé de l'inclure le 8 juillet 2026, et le Chrome Root Program exige que les certificats émis à partir du 15 mars 2027 servent uniquement à l'authentification serveur. Si vous utilisez des certificats publics comme certificats client pour du TLS mutuel (mTLS), ce qui est courant dans les intégrations d'API B2B, ces connexions ont besoin d'une autorité de certification privée.

À 100 jours, puis à 47, installer les certificats à la main cesse d'être une option réaliste. Une entreprise qui automatise en fonction de ce calendrier est aussi prête pour la prochaine révocation massive. Ce qu'il faut pour cela :

1. Savoir ce que vous avez, dans les deux sens. Une liste de tous les certificats que vous servez, avec nom d'hôte, émetteur, date d'expiration, méthode de renouvellement et responsable. Une seconde liste de tous les magasins de confiance sur lesquels repose votre logiciel : le paquet du système d'exploitation, chaque bundle propre à un langage, chaque fichier d'AC à l'intérieur d'une application ou d'un appareil. La recherche CT ci-dessus amorce la première liste ; une nomenclature logicielle (SBOM) ou un inventaire des dépendances amorce la seconde.
2. Automatiser l'émission et l'installation. ACME partout où il peut tourner, avec ARI (RFC 9773) pour qu'une autorité de certification puisse demander à vos clients de renouveler en avance. Là où un appareil ne peut pas exécuter ACME, utilisez l'automatisation du fabricant, ou faites la terminaison TLS en amont, sur un équipement qui en est capable.
3. Garder une seconde autorité de certification prête. Un compte ACME opérationnel chez une seconde autorité, testé, et des enregistrements CAA dans le DNS qui autorisent les deux. Quand une autorité perd la confiance ou révoque en masse, en changer devient une simple modification de configuration.
4. Surveiller CT pour vos domaines. Recevez une alerte pour chaque nouveau certificat émis à vos noms. Vous apprenez une émission inattendue le jour même.
5. Traiter les magasins de confiance comme des dépendances. Mettez-les à jour dans le cadre des correctifs habituels, et reconstruisez les images selon un calendrier plutôt que seulement quand le code change.
6. Rédiger le runbook (la procédure d'intervention) en fonction des deux horloges. 24 heures et cinq jours : qui décide, qui a accès à chaque système, quels systèmes demandent des étapes manuelles, comment joindre chaque fournisseur. Entraînez-vous une fois par an en remplaçant le certificat d'un service qui peut se permettre une erreur. Les autorités de certification publiques doivent tenir et tester leur propre plan de révocation massive depuis 2025 ; leurs clients ont besoin de l'autre moitié.

Si vous fabriquez des produits que d'autres exploitent

Si votre produit contient un magasin de confiance (un appareil, une application installée, un SDK), vos clients ne sont protégés qu'une fois votre mise à jour arrivée chez eux. Livrez-la, et indiquez à vos clients quelles versions sont corrigées. Le conseil de Mozilla aux opérateurs de magasins de confiance : bloquer les huit intermédiaires si votre logiciel le permet, sinon « examiner s'il convient de retirer la confiance accordée aux racines qui ont signé ces intermédiaires ».

Le Cyber Resilience Act s'applique ici de deux façons. Son obligation de signalement, en vigueur depuis le 11 septembre 2026, porte sur les vulnérabilités activement exploitées, et aucune exploitation n'a été signalée dans ce cas. Ses exigences essentielles, applicables à partir du 11 décembre 2027, prévoient notamment que les vulnérabilités puissent être corrigées par des mises à jour de sécurité ; un produit dont la liste de confiance ne peut pas être mise à jour n'y satisferait pas. Les clients soumis à NIS2 demanderont à leurs fournisseurs avec quelle rapidité ils ont traité ce problème, et il vaut mieux avoir la réponse par écrit.

Ce qui reste en suspens

• La racine restante d'eMudhra. Chrome a posé douze questions à eMudhra le 21 octobre et n'a annoncé aucune décision concernant emSign Root CA - G1. Mozilla ne la retire pas « pour le moment ».
• La voie de migration d'eMudhra. eMudhra a indiqué à Mozilla qu'elle transférerait ses clients vers sa hiérarchie G1 (RSA) ; sa page de statut parle d'« une autre hiérarchie d'AC reconnue publiquement et exploitée de manière indépendante ». Chrome a demandé laquelle.
• Microsoft et Apple. Aucun des deux n'a publié de déclaration ni retiré l'une ou l'autre racine de son magasin.
• Les correctifs en attente. Red Hat, Amazon Linux, Temurin et Corretto n'avaient rien livré au 22 octobre ; le correctif de Bun avait été fusionné mais pas publié.
• La cause profonde. eMudhra ne l'a pas confirmée, et a annoncé qu'elle revérifierait chacune des cérémonies des clés qu'elle a menées.
• Sectigo. Dans une affaire distincte, ouverte depuis le 5 septembre, Sectigo a refusé de révoquer des certificats dont l'usage étendu de la clé (EKU) ne correspondait pas à une phrase de sa CPS, en faisant valoir que cette phrase était ambiguë. Le 18 octobre, Sectigo en comptait environ 72 millions encore actifs. Certains participants à la discussion publique ont réclamé un retrait de confiance ; aucun programme de gestion des racines n'a annoncé de décision. Les entreprises qui ont des certificats Sectigo devraient suivre l'affaire.

Où trouver de l'aide

Un problème de certificat s'annonce rarement comme tel. Il se manifeste par une page de paiement qui ne se charge plus, une intégration qui ne se synchronise plus ou un appareil qui ne remonte plus de données, généralement un week-end. Nous aidons les entreprises à traverser des semaines comme celle-ci sans interruption de service, et à s'organiser pour que la prochaine soit une routine :

• Un diagnostic d'exposition. Nous identifions où vos systèmes établissent ou acceptent des connexions TLS, quel magasin de confiance chacun utilise et quels certificats vous servez, y compris les conteneurs, les services Java, les intégrations avec les banques et les prestataires de paiement et de logistique, et les appareils.
• Les correctifs. Mises à jour, images reconstruites, clés bloquées ou certificats remplacés, réalisés dans le cadre de votre processus de gestion des changements et confirmés avec les serveurs de test de Mozilla.
• L'automatisation pour 2027. ACME avec ARI sur les serveurs, les répartiteurs de charge et les appliances, une seconde autorité de certification, des enregistrements CAA, une surveillance CT et un runbook, prêts pour les certificats de 100 jours à partir du 15 mars 2027.
• Les systèmes que personne ne veut toucher. Les anciennes applications Java, les appliances et les clients embarqués dotés de leur propre magasin de confiance sont précisément l'objet de notre service de maintenance de systèmes anciens et de code.

Si vous ne savez pas si vous êtes concerné, écrivez à office@c9group.dev en indiquant les domaines et les plateformes que vous exploitez, ou réservez un appel. Nous vous dirons quoi vérifier en premier.