eMudhra: claves de CA triviales, revocaciones y parches

Tras el secuestro de los ccTLD .gh, .sl y .as, que permitió obtener certificados válidos para dominios ajenos, la confianza en HTTPS vuelve a estar bajo presión, esta vez desde dentro de una autoridad de certificación. Ocho CA intermedias de la india eMudhra tenían claves privadas tan débiles que podían obtenerse en menos de un segundo a partir de los certificados públicos. Con una de estas claves se puede firmar un certificado para cualquier dominio, aceptado por todos los clientes que aún confían en esas CA.

Qué ha pasado

El 17 de octubre de 2026 a las 20:06 UTC, Mozilla recibió, reenviado por el Chrome Root Program, el aviso de un investigador que firma como «Wayne». Según Help Net Security, lo descubrió revisando los datos públicos de la Common CA Database (CCADB) y, como prueba, firmó con cada clave el mensaje «We have a problem here – Wayne», que envió a Apple, Google, Microsoft, Mozilla y eMudhra. Mozilla recuperó las claves por su cuenta a las 21:48 UTC del mismo día, sin conocer el método del investigador.

La respuesta, según SecurityWeek y Help Net Security:

• 17 de octubre: Firefox bloquea las intermedias con OneCRL y Chrome bloquea las seis intermedias TLS con los CRLSet, sin actualizar ni reiniciar el navegador; Android y los Chromebook reciben un bloqueo equivalente a través de Google Play Services;
• 18 de octubre: eMudhra revoca los ocho certificados;
• 19 de octubre: Apple distribuye las protecciones; Cloudflare, informada ese día, actualiza sus servicios y clientes y no detecta explotación;
• 20 de octubre: Microsoft bloquea los certificados; Mozilla publica Firefox 158.0.1 y actualizaciones ESR para las configuraciones que no habían recibido el bloqueo. Sin embargo, Ars Technica informaba de que ese día Edge en Windows 10 aún se conectaba a 12 hosts vulnerables.

Mozilla retiró la confianza en la raíz emSign ECC Root CA – G3, que firma las intermedias; según CSO Online, Google la retira del Chrome Root Store con efecto en todos los dispositivos a partir del 27 de octubre. eMudhra ha dejado de emitir bajo esa raíz y calcula que hay que sustituir unos 30.000 certificados de clientes (la misma cifra la da a CSO Online Yash Kadakia, de Security Brigade).

Detalles técnicos

Según el informe de Mozilla citado por la prensa, las ocho intermedias proceden de un lote de 24 generado el 30 de abril de 2025: seis emiten certificados TLS y dos sirven para la firma de código. Help Net Security escribe que Sectigo firmó de forma cruzada las ocho en mayo de 2025; BleepingComputer solo habla de «algunas».

Una clave privada ECC P-384 debería ser un número aleatorio de 384 bits. Las de eMudhra eran todas inferiores a 256: 4, 56, 66, 115, 155, 156, 230 y 237. Dennis Jackson, de Mozilla, las describe como «todo ceros salvo el último byte», recuperables casi al instante con el algoritmo de logaritmo discreto baby-step giant-step; aunque basta también con probar los 256 valores posibles. Varias personas las obtuvieron de forma independiente y una se publicó en GitHub.

La explicación de eMudhra: en la ceremonia de generación de claves, con HSM FIPS 140-2 Nivel 3, un error del script hizo que un paso de wrap/unwrap produjera un segundo conjunto de claves débiles junto a las correctas. Las claves débiles tenían etiquetas parecidas y se eligieron para las solicitudes de certificado. La empresa admite errores humanos en varios pasos; afirma que las intermedias estaban destinadas a sus centros de datos de Estados Unidos y Europa, que solo una entró en producción, que ninguna emitió certificados finales y que las claves de las raíces no están afectadas. Recuerda que raíces e intermedias habían superado auditorías independientes durante dos años y volverá a revisar todas las ceremonias realizadas.

Google afirma que en los registros de Certificate Transparency (CT) no aparecen certificados TLS vinculados a las seis intermedias antes del bloqueo, por lo que los clientes que aplican CT, como Chrome en su configuración predeterminada, no podían verse afectados. Pero no todos los clientes aplican CT, y quien tuviera una clave podía firmar certificados sin pasar por eMudhra: no se sabe si alguien lo hizo en los 17 meses anteriores. Las fuentes no detallan el impacto de las dos intermedias de firma de código.

Para aprovechar un certificado falso hace falta un ataque adversary-in-the-middle: según Ars Technica está al alcance de actores con muchos recursos, pero es mucho más fácil para quien controla una red local.

MITRE ATT&CK (clasificación nuestra): T1588.004 (Obtain Capabilities: Digital Certificates), T1557 (Adversary-in-the-Middle), T1553.002 (Subvert Trust Controls: Code Signing) para las intermedias de firma de código.

Impacto para las empresas europeas e italianas

Los navegadores están protegidos, el resto no. Aplicaciones con su propia lista de raíces, servidores, contenedores y dispositivos que no comprueban la revocación pueden seguir confiando en las intermedias hasta que se actualicen. Filippo Valsorda, entrevistado por Ars Technica, prevé una «cola larguísima»: dispositivos IoT, contenedores Docker, máquinas Linux olvidadas, herramientas de línea de comandos con su propia copia de las raíces.

Para las entidades sujetas a NIS2 es un caso concreto de riesgo de la cadena de suministro: la confianza depende de terceros que nunca se eligieron directamente. En sanidad y en la industria pesan los equipos con ciclos de actualización largos. Si tienes certificados de eMudhra bajo la raíz G3, debes sustituirlos antes de que la raíz se retire de los almacenes de confianza.

Qué hacer ya

1. Actualiza los paquetes de raíces. Estado a 20 de octubre, según el tracker de Jackson citado por BleepingComputer, entre otros: Ubuntu ca-certificates 20260816ubuntu0.*.1, Alpine 20261020-r0, Arch ca-certificates-mozilla 3.131.1-1, NSS 3.131.1, Python certifi 2026.10.19, pip 26.2.2, rustls-webpki 0.103.16, webpki-roots 1.0.10, Electron 44.9.1, 43.8.1 y 42.11.16, Composer ca-bundle 1.4.16 y 1.6.0; Go 1.27.3 y 1.26.10 (CVE-2026-111943, citada solo por BleepingComputer). Debian, FreeBSD, Node.js y Bun seguían pendientes.
2. Reconstruye imágenes y contenedores con las raíces actualizadas: una copia incorporada no se actualiza sola.
3. Busca almacenes de confianza separados, como sugiere Kadakia: pasarelas de pago, integraciones con proveedores, aplicaciones Java antiguas, apps móviles, equipos de red. En macOS, según Jackson, /usr/bin/curl puede seguir confiando porque no comprueba la revocación.
4. Comprueba que los clientes rechacen las cadenas comprometidas, incluidas las de firma cruzada, con los endpoints de prueba del sitio de Jackson.
5. Sustituye los certificados de eMudhra emitidos bajo emSign ECC Root CA – G3 para tus servicios.
6. Supervisa los registros CT de tus dominios, como ya se indicó para el caso de los ccTLD.

Cómo ayuda ARXDOME

ARX Expose muestra cada día la superficie de ataque externa, incluidos nombres y certificados de los servicios públicos: te ayuda a encontrar los que hay que sustituir. En las sedes aprobadas, el escaneo activo de ARX Watch identifica los certificados de los dispositivos internos, también de los que no tienen sonda.

Última actualización: 22 de octubre de 2026