eMudhra quitte le marché mondial des SSL après la découverte de clés faibles

L'autorité de certification indienne eMudhra a annoncé jeudi qu'elle quitterait son activité mondiale de certificats SSL/TLS. Cette décision fait suite à la découverte par un chercheur en sécurité que huit des clés privées de ses autorités de certification (CA) intermédiaires étaient gravement faibles et facilement récupérables. Les principaux éditeurs de navigateurs, dont Google et Mozilla, ont déjà commencé à ne plus faire confiance aux certificats racines affectés, impactant des dizaines de milliers de sites web.

Ce qui s'est passé

L'incident a débuté le 17 octobre lorsqu'un chercheur a signalé à Apple, Google, Microsoft, Mozilla et eMudhra que huit clés privées d'autorités de certification intermédiaires étaient compromises. Ces clés, qui auraient dû être de grands nombres aléatoires, étaient toutes inférieures à la valeur 256. Cette extrême faiblesse signifiait que n'importe qui pouvait calculer les clés privées presque instantanément, brisant ainsi efficacement le modèle de confiance cryptographique pour tout certificat émis sous leur autorité. Six de ces huit clés ont été utilisées pour des certificats TLS de sites web.

En réponse, Chrome et Firefox ont bloqué les six intermédiaires TLS affectés dans les heures suivant le signalement. Google a confirmé qu'aucun certificat de site web provenant de ces intermédiaires n'était apparu dans les journaux publics de transparence des certificats avant le blocage, ce qui signifie qu'ils n'ont probablement pas servi à émettre des certificats valides aux utilisateurs finaux. eMudhra a déclaré que ses systèmes n'avaient pas été compromis et qu'elle n'avait jamais utilisé ces clés faibles spécifiques pour émettre des certificats aux clients. Cependant, les dommages causés à la confiance ont été immédiats et sévères.

Suite à cette divulgation, le conseil d'administration d'eMudhra a décidé de se retirer entièrement du marché mondial SSL/TLS. L'entreprise a indiqué que ce segment ne représentait qu'environ 1 % de son chiffre d'affaires et impliquait des coûts complexes liés à la souveraineté des données et à la conformité. Elle a également noté que l'examen sur les réseaux sociaux entourant l'incident était disproportionné par rapport à la taille de l'activité. eMudhra continuera d'exploiter ses autres services, y compris les signatures numériques et la plateforme CertiNext, mais cessera d'émettre de nouveaux certificats TLS mondiaux.

Détails clés

• Chrome cessera de faire confiance au certificat racine emSign ECC Root CA - G3 le matin du 27 octobre, heure du Pacifique.
• Mozilla a décidé le 20 octobre de cesser de faire confiance à la même racine dans Firefox, coupant ainsi l'accès aux certificats légitimes chaînés à celle-ci.
• Environ 30 800 certificats non expirés étaient chaînés à la racine affectée au 21 octobre, selon le décompte de Chrome.
• Environ 99,9 % des certificats affectés ont été émis via InCommon, un service destiné à la communauté de l'enseignement supérieur.
• eMudhra estime qu'environ 30 000 certificats doivent être remplacés, dont 97 % émis via le protocole ACME.
• Les clients ACME standard ne remplacent pas automatiquement les certificats en dehors de leur fenêtre de renouvellement, sauf s'ils prennent en charge les informations de renouvellement ACME (ARI).

Contexte

Pour comprendre la gravité de la situation, il est utile de savoir comment fonctionne la confiance TLS. Les navigateurs et les systèmes d'exploitation maintiennent un « magasin racine » d'autorités de certification fiables. Lorsqu'un site web présente un certificat, le navigateur vérifie s'il peut être chaîné jusqu'à l'une de ces racines fiables. Si la racine est retirée du magasin, comme cela s'est produit avec la racine ECC d'eMudhra, tous les certificats émis sous son autorité deviennent non fiables. Les utilisateurs verront des avertissements de sécurité et les systèmes automatisés pourraient échouer à établir une connexion.

La défaillance spécifique ici concernait les clés privées des autorités de certification intermédiaires. Une CA intermédiaire se situe entre la racine et le certificat de l'utilisateur final. Si la clé privée d'une CA intermédiaire est connue, un attaquant peut émettre des certificats frauduleux pour n'importe quel domaine. Dans ce cas, les clés étaient si petites (inférieures à 256) qu'elles n'offraient aucune sécurité. Bien qu'eMudhra affirme que ces clés n'ont pas été utilisées pour l'émission, la simple existence de telles clés faibles dans un environnement de production signale une défaillance critique dans les processus de génération de clés.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés ou des services internes, cet incident met en lumière la fragilité liée à la dépendance à un seul fournisseur de certificats. Même si votre site public utilise une autre CA, vos outils internes ou intégrations partenaires pourraient reposer sur des certificats émis par eMudhra. Avec le retrait de la confiance par Chrome et Firefox, tout service dépendant de ces certificats sera interrompu. Cela inclut les API, les microservices et les intégrations tierces qui valident strictement les chaînes TLS.

Le processus de transition est également complexe. Google a demandé aux opérateurs d'acquérir immédiatement de nouveaux certificats auprès d'une hiérarchie PKI différente. Cependant, passer d'une racine basée sur ECC à une racine basée sur RSA, ou vers un fournisseur complètement différent, nécessite souvent une intervention manuelle. Les outils automatisés comme les clients ACME peuvent ne pas gérer sans heurt les remplacements hors bande, surtout s'ils ne prennent pas en charge les informations de renouvellement ACME. Cela crée une vague de travail manuel pour les équipes IT et DevOps qui doivent traquer chaque point de terminaison affecté.

De plus, l'incident soulève des questions sur la transparence et l'hygiène opérationnelle. eMudhra avait publié des listes de révocation de certificats (CRL) invalides en 2025 pour des intermédiaires similaires, affirmant à l'époque avoir résolu le problème en régénérant les CRL avec des clés appropriées. La découverte récente suggère que ces corrections pourraient avoir impliqué une signature avec des clés défectueuses, un détail non divulgué dans le rapport précédent. Ce manque de clarté rend difficile pour les clients d'évaluer le risque lié aux racines restantes d'eMudhra, telles que la racine RSA G1, qui est toujours en cours d'examen par Chrome.

Ce que vous pouvez faire

• Auditez votre inventaire pour tout certificat émis par eMudhra, en particulier ceux chaînés à emSign ECC Root CA - G3.
• Vérifiez si vos services font partie de la fédération InCommon, car 99,9 % des certificats affectés appartiennent à ce groupe.
• Remplacez immédiatement les certificats affectés par ceux issus d'une hiérarchie CA différente et fiable, telle que Let's Encrypt ou un fournisseur commercial.
• Vérifiez que vos clients ACME prennent en charge les informations de renouvellement ACME (ARI) pour mieux gérer les futurs remplacements forcés.
• Surveillez le statut de la racine RSA G1 d'eMudhra, car Chrome n'a pas encore décidé de la conserver dans son magasin racine.
• Mettez à jour vos systèmes de surveillance pour alerter sur les changements de certificats et les problèmes de confiance, afin de détecter les racines non fiables avant les utilisateurs.