La vulnerabilidad de los certificados de eMudhra afecta a ocho claves privadas de autoridades de certificación intermedias que pudieron recuperarse debido a un fallo de generación en 2025. Chrome y Firefox bloquearon las seis claves TLS en octubre de 2026, pero las aplicaciones, los contenedores, los SDK y los dispositivos que utilizan su propio almacén de confianza deben probarse por separado. Una cadena de confianza aceptada puede permitir validar un certificado falso.
¿Qué ocurrió con los certificados de eMudhra?
La vulnerabilidad de los certificados de eMudhra se debe a ocho claves de autoridades intermedias creadas el 30 de abril de 2025 con una entropía insuficiente, es decir, con muy poca aleatoriedad. El 17 de octubre de 2026, un investigador demostró que controlaba las ocho claves privadas. Mozilla recuperó una de ellas de forma independiente, lo que confirmó que su explotación era técnicamente trivial.
Una autoridad de certificación intermedia es una entidad digital autorizada por una autoridad raíz para firmar otros certificados. Seis claves comprometidas se utilizaban para el protocolo TLS, que cifra, entre otras, las conexiones HTTPS, y dos para la firma de código.
Según CERT-In, los valores privados P-384 afectados eran enteros inferiores a 256. Por tanto, podían recuperarse casi instantáneamente a partir de las claves públicas, mientras que una clave elíptica correctamente generada debe ser imposible de adivinar en la práctica.
eMudhra explicó el 21 de octubre de 2026 que una fase de script «wrap/unwrap» había creado un segundo conjunto de claves débiles y que, posteriormente, unas etiquetas similares habían llevado a utilizar esas claves en las solicitudes de firma. El 26 de octubre de 2026, la investigación de la causa raíz seguía figurando como en curso. Por tanto, se trata de la explicación publicada por la empresa, no de un informe final independiente.
¿Qué riesgo crea la vulnerabilidad de los certificados de eMudhra?
La posesión de una clave TLS intermedia comprometida permitía firmar certificados falsos para cualquier dominio, siempre que el cliente siguiera considerando fiable la cadena de eMudhra y no exigiera Certificate Transparency. El atacante también debía interceptar o desviar la conexión para presentar el certificado falsificado a su objetivo.
Certificate Transparency est un système de journaux publics qui rend contrôlable l’émission des certificats du Web. Google a indiqué le 20 octobre 2026 n’avoir trouvé, avant son blocage, aucun certificat TLS lié aux six intermédiaires compromis dans ces journaux. Ce constat écarte leur usage contre les clients qui imposaient ce contrôle, mais pas contre les clients sans contrôle CT.
eMudhra declaró el 21 de octubre de 2026 que siete certificados intermedios nunca se habían desplegado y que el octavo no había emitido ningún certificado final. La empresa también afirmó no haber encontrado pruebas de una recuperación maliciosa de las claves antes de su divulgación. La ausencia de pruebas no significa que se haya demostrado la ausencia, pero afirmar que se produjo un ataque sería inexacto.
La trampa para un responsable de la toma de decisiones consiste en confundir un certificado comprometido con un sitio pirateado. La vulnerabilidad de los certificados de eMudhra afecta al mecanismo de confianza: puede facilitar la suplantación de un servicio ante determinados clientes, sin demostrar una intrusión en el servidor, la base de datos o la cuenta de alojamiento.
¿Protegen ya Chrome y Firefox a su empresa?
Chrome bloqueó las seis claves TLS mediante CRLSet el 17 de octubre de 2026 a las 19:45 UTC y, posteriormente, Firefox terminó de distribuir OneCRL a las 22:59 UTC. Según Mozilla, estos mecanismos de revocación se aplicaron sin reiniciar ni actualizar completamente el navegador en las configuraciones estándar.
Mozilla publicó después Firefox 158.0.1, Firefox ESR 115.43.1, Firefox ESR 153.5.1 y NSS 3.131.1 el 20 de octubre de 2026. NSS, la biblioteca de seguridad de Mozilla, retiró la raíz emSign ECC Root CA - G3 para el software que utiliza el almacén de Mozilla sin recibir OneCRL. Firefox para Android 158.0.2 llegó posteriormente, el 21 de octubre de 2026.
Google programó para el 27 de octubre de 2026 la retirada de esa misma raíz en los dispositivos estables que utilizan Chrome Root Store, especialmente para ampliar la protección a los clientes que no reciben CRLSet. La diferencia entre las versiones de Chrome y Firefox recuerda que una función o protección distribuida por el navegador nunca se aplica de manera uniforme a todo un parque.
Esta es la diferencia operativa entre los principales entornos afectados en 2026.
| Medio ambiente | Medida publicada en 2026 | Verificación que debe realizarse |
|---|---|---|
| Chrome estándar | Bloqueo mediante CRLSet el 17 de octubre | Comprobar la recepción de las políticas y Chrome Root Store |
| Firefox estándar | Bloqueo mediante OneCRL el 17 de octubre; versiones corregidas el 20 de octubre | Comprobar la versión y la aplicación de OneCRL |
| Aplicación con NSS | Retirada de la raíz en NSS 3.131.1 el 20 de octubre | Identificar y actualizar la versión de NSS integrada |
| Contenedor, SDK o aplicación Electron | Ninguna protección universal | Probar el motor TLS y el archivo de autoridades que se cargan realmente |
| Dispositivo integrado | Depende del fabricante y del firmware | Probar el dispositivo y solicitar posteriormente una corrección al proveedor |
¿Cómo comprobar si un sitio o una aplicación siguen expuestos?
La comprobación de la vulnerabilidad de los certificados de eMudhra debe inventariar las cadenas del servidor y del cliente que contengan EM DV/OV/EV TLS CA - G3B, EM DV/OV/EV TLS CA - G3C, sus equivalentes cofirmados por Sectigo o emSign ECC Root CA - G3. Cada prueba debe utilizar el motor TLS y el almacén de autoridades de la aplicación real.
Abrir el sitio en el navegador personal no es suficiente. Una API puede funcionar en Chrome y seguir siendo vulnerable desde un contenedor Linux antiguo, una aplicación Electron, un terminal de pago o un SDK móvil que incluya su propia lista de autoridades. Es el mismo tipo de diferencia de entorno que la corrección de una vulnerabilidad en NAS y Docker.
Un inventario práctico sigue cinco pasos:
- recenser les domaines, API, applications mobiles, conteneurs, automates, VPN et équipements qui ouvrent des connexions TLS ;
- extraer la cadena presentada por cada servidor y buscar los nombres de eMudhra afectados, incluidas las copias cosuscritas por Sectigo;
- identificar, en el lado del cliente, la biblioteca TLS y el almacén de autoridades que se utilizan realmente;
- tester les connexions avec la configuration exacte de production, puis consigner les connexions acceptées et refusées ;
- preparar la sustitución de los certificados legítimos que dependen de la raíz retirada antes de eliminar esta del parque.
El verificador independiente publicado el 22 de octubre de 2026 propone, entre otras, la orden curl https://dv-g3b-emudhra.we-have-a-problem.com/. Una conexión correcta indica que el cliente probado haorceptado la cadena presentada. Los puntos de conexión sin Certificate Transparency y las cadenas PEM descargables también permiten realizar validaciones hor línea con OpenSSL.
En los proyectos que llevamos a cabo, a menudo vemos que la auditoría se detiene en el certificado presentado por el servidor público. Lo adecuado es probar también los consumidores de la API: tareas programadas, aplicaciones móviles, imágenes Docker y software empresarial. La gestión de secretos debe examinarse por separado, como ilustra la protección de las claves de API tras un incidente.
¿Hay que eliminar inmediatamente la raíz de eMudhra?
Eliminar emSign ECC Root CA - G3 bloquea las cadenas que dependen de esta raíz, pero también puede interrumpir conexiones legítimas. Google confirmó este riesgo el 22 de octubre de 2026. Los operadores afectados deben obtener y desplegar primero un certificado vinculado a otra jerarquía de confianza y, después, retirar la cadena antigua.
Mozilla estimaba en Bugzilla, el 21 de octubre de 2026, que aproximadamente 30 800 precertificados no caducados estaban vinculados a la raíz G3 retirada, principalmente a través de dos autoridades suborordinadas de Internet2/InCommon. Estos certificados legítimos no procedían de los ocho intermediarios débiles. Ilustran el posible coste colateral de aplicar la desconfianza a toda la raíz.
eMudhra revocó los ocho intermediarios el 18 de octubre de 2026 con el motivo caCompromise. Las copias cosuscritas por Sectigo utilizaban las mismas claves públicas comprometidas; por tanto, cambiar únicamente la ruta de certificación no corrrige el problema.
El 22 de octubre de 2026, el consejo de administración de eMudhra decidió abandonar el mercado mundial de certificados SSL/TLS. La empresa anunció certificados de sustitución durante la transición y el mantenimiento de los servicios de estado hasta la caducidad o sustitución de los certificados emitidos. Sinceramente, mantener de forma permanente una dependencia de esta jerarquía no se justifica corando es posible volver a emitirlos a través de una autoridad encor confiable aprobada.
¿Qué plan de acción se debe aplicar sin provocar una interrupción?
El tratamiento de la vulnerabilidad de los certificados de eMudhra debe separar la urgencia del cliente de la migración del servidor. Primero hay que bloquear las autoridades comprometidas en cada entorno vulnerable y, después, volver a emitir los certificados legítimos antes de retirar la raíz G3. Un despliegue progresivo con supervisión evita que una cororrección de seguridad deje fuera de servicio una API empresarial.
Desde el lado de la agencia, lo recomendable es elaborar una matriz «servicio, cliente, motor TLS, almacén de confianza, responsable». Este documento sencillo revela las dependencias olvidadas y permite asignar cada cororrección. Sin un responsable identificado, los contenedores antiguos y los dispositivos integrados quedan con frecuencia forera del plan.
Prevea una reversión para cada cambio, pero no una vuelta permanente a la confianza comprometida. En un servidor, despliegue primero la nueva cadena y verifíquela desde todos los clientes representativos. En un parque de clientes, actualice el almacén de autoridades o la biblioteca, controle los registros de errores TLS y, a continuación, retire las excepciones tempororales.
Definir la verificación de las cadenas, las bibliotecas TLS y los certificados de sustitución evita la mayoría de las interrupciones inesperadas. Una revisión externa puede ser especialmente útil corando una aplicación depende de varios proveedores, imágenes de contenedores o dispositivos cuya cadena completa nadie domina por sí solo.
Preguntas frecuentes sobre el incidente de eMudhra
¿Demuestra una cadena HTTPS que mi certificado es seguro?
El candado HTTPS indica que un navegador ha aceptado la conexión y su certificado. El candado no demuestra que otro cliente, que utilice un almacén de autoridades de certificación diferente, bloquee correctamente las claves de eMudhra comprometidas.
¿Qué nombres de certificados de eMudhra hay que buscar?
Los controles deben buscar EM DV/OV/EV TLS CA - G3B, EM DV/OV/EV TLS CA - G3C, sus versiones cosuscritas por Sectigo y la raíz emSign ECC Root CA - G3.
¿La actualización del navegador protege una aplicación Electron?
Una actualización de Chrome o Firefox no garantiza la protección de una aplicación Electron. La aplicación Electron puede incluir su propio entorno de ejecución, su biblioteca TLS o un almacén de autoridades independiente que debe probarse y actualizarse.
¿Existe alguna prueba de explotación maliciosa de las claves?
No se había confirmado ninguna explotación maliciosa en la información publicada hasta el 27 de octubre de 2026. eMudhra afirmaba no haber encontrado ninguna prueba anterior a la divulgación, mientras que la recuperación independiente de las claves demostraba que el ataque era técnicamente sencillo.