Des sites gouvernementaux indiens continuent de servir des certificats eMudhra révoqués après une révocation massive

Un incident majeur impliquant l'autorité de certification eMudhra a laissé des centaines de sites web gouvernementaux indiens servant des certificats numériques révoqués. Le problème est apparu à la mi-octobre 2026 lorsque les clés privées de plusieurs autorités de certification intermédiaires ont été compromises, conduisant à la défiance envers la racine emSign ECC Root CA - G3 par les principaux navigateurs comme Chrome et Mozilla.

Ce qui s'est passé

Le 17 octobre 2026, des chercheurs en sécurité ont découvert que huit autorités de certification intermédiaires d'eMudhra, chaînées à la racine emSign ECC Root CA - G3, possédaient des clés privées trivialement récupérables. Ces clés ont été révoquées le lendemain. En réponse, Mozilla et Chrome ont décidé de ne plus faire confiance à l'ensemble de la racine G3. Parallèlement, le 19 octobre, eMudhra a révoqué 9 356 certificats sur sa hiérarchie RSA non affectée, connue sous le nom de emSign Root CA - G1. La raison invoquée pour cette révocation massive était « Superseded » (Remplacé), touchant tous les certificats non expirés qui manquaient d'un OID de politique de type de certificat spécifique requis par la déclaration de pratique de certification d'eMudhra elle-même.

Le Ministère de l'Électronique et des Technologies de l'Information (MeitY) a tenté de minimiser la gravité de l'incident le 21 octobre. Un message sur les réseaux sociaux du ministère affirmait que l'impact sur les sites web indiens était très limité et de courte durée. Cette évaluation contredit les preuves techniques montrant que les clés défaillantes existaient depuis avril 2025, permettant une récupération potentielle pendant dix-huit mois. De plus, l'événement de révocation a causé des perturbations généralisées, eMudhra estimant que 30 000 certificats issus d'autorités intermédiaires non affectées nécessitent une migration, dont beaucoup appartiennent à des universités américaines plutôt qu'à des entités indiennes.

Malgré les assurances officielles, les sites gouvernementaux indiens servent toujours des certificats révoqués plusieurs jours après l'incident. Quatre organismes relevant directement du MeitY, y compris le Controller of Certifying Authorities (CCA), qui régule eMudhra, figurent parmi les entités affectées. Une analyse actualisée le 24 octobre a identifié 1 377 noms de domaine gouvernementaux indiens utilisant des certificats révoqués, dont 811 les servant encore activement. Les services notables impactés incluent le traitement des visas, les portails d'immigration, les plateformes de services aux citoyens comme ICEGATE, et les ressources éducatives.

Détails clés

• Huit CAs intermédiaires d'eMudhra avaient des clés privées récupérables générées en avril 2025, conduisant à leur révocation le 18 octobre 2026.
• Le 19 octobre 2026, eMudhra a révoqué 9 356 certificats sur sa hiérarchie RSA en raison d'OIDs de politique manquants, affectant 2 976 noms de domaine gouvernementaux.
• Au 24 octobre 2026, 811 domaines gouvernementaux indiens servaient encore des certificats révoqués, y compris des services critiques comme indianvisaonline.gov.in.
• Le comportement des navigateurs varie considérablement : Firefox bloque ces sites via CRLite, tandis que Chrome, Edge et Safari autorisent souvent l'accès en raison de listes de révocation incomplètes.
• SSL Labs attribue une note Grade F à ces sites, les marquant comme révoqués, mais ils restent accessibles à de nombreux utilisateurs selon leur logiciel client.
• Le Controller of Certifying Authorities, le régulateur d'eMudhra en Inde, sert lui-même un certificat eMudhra révoqué sur son site PKI.

Contexte

Les certificats Transport Layer Security (TLS) vérifient l'identité des sites web et chiffrent les données en transit. Les Autorités de Certification (CA) comme eMudhra délivrent ces certificats. Lorsqu'une CA découvre une faille de sécurité ou une erreur de configuration, elle doit révoquer les certificats affectés. La révocation informe les navigateurs qu'un certificat précédemment fiable n'est plus valide. Les navigateurs vérifient le statut de révocation en utilisant des mécanismes tels que les Listes de Révocation de Certificats (CRLs), le Protocole de Statut de Certificat en Ligne (OCSP), ou des ensembles compacts comme CRLite et CRLSet.

Dans ce cas, l'incohérence provient du fait que différents navigateurs utilisent différentes méthodes pour vérifier la révocation. Firefox utilise CRLite, qui couvre toutes les révocations et bloque l'accès immédiatement. Chrome utilise CRLSet, qui n'avait pas inclus ces certificats spécifiques fin octobre, permettant aux connexions de se poursuivre. Cette fragmentation signifie que certains utilisateurs voient des erreurs tandis que d'autres non, créant un faux sentiment de sécurité pour ceux dont les navigateurs n'appliquent pas la révocation.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés ou des infrastructures internes, cet incident met en lumière la fragilité de dépendre uniquement des autorités de certification externes sans surveillance indépendante. Si une CA majeure omet de notifier ses abonnés ou si l'application par les navigateurs est incohérente, vos services peuvent sembler fonctionnels pour certains utilisateurs tout en étant signalés comme non sécurisés par d'autres. Cela peut entraîner des risques d'exposition des données, une perte de confiance des utilisateurs et des violations de conformité, en particulier pour les organisations traitant des données sensibles de citoyens ou de clients.

Le délai dans le remplacement des certificats révoqués démontre également des lacunes opérationnelles. Même lorsque les révocations sont émises, la migration de milliers de certificats prend du temps et nécessite une coordination. Sans alertes automatisées et visibilité sur le statut des certificats, les équipes IT peuvent rester ignorantes de la dégradation de leurs services jusqu'à ce que les utilisateurs signalent des problèmes. Pour les entités gouvernementales et les entreprises, ce retard peut perturber des services critiques comme les demandes de visa ou les déclarations fiscales, causant des préjudices concrets.

De plus, l'ironie réglementaire consistant à voir le régulateur lui-même servir un certificat révoqué souligne la nécessité d'audits internes rigoureux. La conformité ne consiste pas seulement à obtenir un certificat, mais à maintenir sa validité tout au long de son cycle de vie. Les équipes doivent supposer que les notifications externes peuvent être retardées ou incomplètes, rendant la surveillance proactive essentielle pour maintenir la disponibilité et la posture de sécurité.

Ce que vous pouvez faire

• Mettre en œuvre une surveillance automatisée des certificats TLS qui vérifie le statut de révocation indépendamment du comportement du navigateur, en utilisant des outils qui interrogent directement les CRLs et les répondants OCSP.
• Configurer des alertes pour l'expiration et les événements de révocation des certificats afin de garantir que votre équipe soit notifiée avant que les utilisateurs ne rencontrent des erreurs de connexion.
• Auditer régulièrement votre inventaire de certificats pour identifier tout certificat émis par des CA subissant des incidents de sécurité ou des événements de défiance racine.
• Tester vos services sur plusieurs navigateurs et appareils pour comprendre comment les différents mécanismes de vérification de révocation affectent l'accès utilisateur.
• Maintenir un plan de contingence pour le remplacement rapide des certificats, incluant une automatisation préconfigurée pour déployer de nouveaux certificats à partir de CA alternatives si nécessaire.
• Examiner vos déclarations de pratique de certification et assurer que vos certificats incluent tous les OIDs de politique requis pour éviter les révocations massives dues à des erreurs de conformité.