Chrome y Firefox bloquearon en horas las claves débiles de eMudhra, pero servidores y contenedores siguen expuestos

El sábado 17 de octubre de 2026, a las 18:05 UTC, un investigador identificado como Wayne avisó a Google, Mozilla, Apple, Microsoft y eMudhra de un fallo grave en esa autoridad de certificación india. Las claves privadas de ocho de sus certificados intermedios podían calcularse a partir de los certificados públicos. Cien minutos después, según el cronograma de Google, Chrome ya bloqueaba los seis intermedios autorizados para TLS con una actualización de CRLSet que no exigía reiniciar el navegador. Firefox lo hizo esa misma noche, Apple el día 19 y Microsoft, en Windows, el 20.

Fuera del navegador el ritmo es otro. El rastreador que mantiene Dennis Jackson, ingeniero de criptografía de Mozilla, enumera 37 programas y paquetes que han necesitado una corrección específica, desde el paquete ca-certificates de varias distribuciones hasta Java, Go, Node.js, el paquete certifi de Python o Electron. Al consultarlo el 22 de octubre, tres figuraban como pendientes, y la lista no incluye RHEL, que tampoco tenía paquete corregido. Esa parte del incidente recae en los equipos de sistemas y desarrollo.

¿Qué falló en las claves de eMudhra?

Una autoridad de certificación firma los certificados digitales de los sitios web a través de certificados intermedios, que a su vez cuelgan de una raíz incluida en los almacenes de confianza. Quien posee la clave privada de un intermedio de confianza puede emitir un certificado válido para el dominio que elija y suplantar un servicio ante los clientes cuya conexión pueda interceptar.

El análisis preliminar de Mozilla, publicado en el informe de incidente de Bugzilla, resume el problema en una frase: "las 8 claves afectadas usaban enteros menores que 256". Eran claves de curva elíptica P-384 cuyo valor privado era prácticamente cero salvo en el último byte. BleepingComputer comprobó por su cuenta que una clave publicada por un investigador, con valor 4, correspondía al intermedio "EM OV TLS CA - G3C".

Las ocho claves pertenecían a un lote de 24 generado el 30 de abril de 2025. Seis eran intermedios TLS (validación de dominio, de organización y extendida) y dos de firma de código. Colgaban de las raíces emSign Root TLS CA - G3 y emSign Root CS CA - G3, que tienen firma cruzada de emSign ECC Root CA - G3. Además, Sectigo emitió en mayo de 2025 una firma cruzada para cada intermedio bajo su raíz AAA Certificate Services.

La explicación de eMudhra, recogida en el mismo informe, combina un error humano con un defecto de código. Durante la ceremonia se añadió, como desviación autorizada, una prueba de exportación e importación cifrada de claves (wrap/unwrap), porque esas claves debían exportarse. El script creó en el módulo de seguridad hardware (HSM) un segundo par de claves, más débiles, y esas claves se usaron por error para generar las solicitudes de certificado porque sus etiquetas se parecían a las de las correctas.

Cómo llegaron a generarse claves con valores tan pequeños sigue sin aclararse. Un participante del debate en Mozilla recuerda que la generación aprobada dentro de un HSM no produce por sí sola un escalar privado menor que 256. Ese mismo participante pide el número de certificado CMVP de los equipos, que eMudhra describe como conformes con FIPS 140-2 nivel 3. La empresa sostiene que sus sistemas no fueron comprometidos, que los intermedios no emitieron certificados a usuarios finales y que el fallo pasó inadvertido unos 18 meses.

¿Por qué el navegador estuvo protegido tan pronto?

Los navegadores cuentan con canales de revocación que el fabricante distribuye a todas las instalaciones sin intervención del usuario, como CRLSet en Chrome y OneCRL en Firefox. En Android, Google distribuyó una actualización de Google Play Services hacia las 22:00 UTC del lunes 19, que según la empresa había llegado a la mayoría de dispositivos el día 20. El CRLSet bloquea por clave pública, así que cubre también las firmas cruzadas de Sectigo.

El aviso llegó al buzón oficial de Mozilla a las 20:06 UTC del 17, reenviado por Chrome. Mozilla había recuperado las claves por su cuenta a las 21:48 y completó el bloqueo a las 22:59. Para las instalaciones que no reciben esos ajustes remotos publicó Firefox 158.0.1 y las versiones ESR 115.43.1 y 153.5.1 (CVE-2026-113470). En Firefox para Android, algunos perfiles no aplicaban la lista al arrancar hasta la versión 158.0.2, del 21 de octubre.

La transparencia de certificados (CT) añade otra barrera. Son registros públicos donde debe anotarse cada certificado TLS de confianza pública, y Chrome exige esa anotación por defecto. Google afirma que ningún certificado TLS encadenado a estos intermedios figuraba en los registros antes del bloqueo. Para un cliente que aplica CT, un certificado fraudulento habría tenido que publicarse antes de ser aceptado, y eso lo habría delatado.

¿Dónde se sigue confiando en esos intermedios?

El riesgo persiste en los programas que llevan una copia de las raíces sin corregir y que, además, no consultan la revocación ni aplican CT. BleepingComputer recoge la advertencia de Jackson sobre el curl que trae macOS en /usr/bin/curl, que no consulta la revocación. El rastreador amplía la lista: en macOS, curl, git, python3, perl, ruby y openssl leen /etc/ssl/cert.pem, que no se había actualizado, y el pip incorporado usa raíces antiguas.

¿Cómo protege Windows frente a estos intermedios?

Según el rastreador, Microsoft distribuye el bloqueo con las actualizaciones automáticas de la lista de confianza de Windows. Para equipos sin esas actualizaciones, el rastreador ofrece un script que añade 16 certificados al almacén de no confiables y protege lo que valida con el almacén y el motor de cadenas del sistema, como Schannel para TLS y Authenticode para firma de código. Las aplicaciones que empaquetan sus raíces necesitan una actualización aparte.

¿En qué punto están las distribuciones Linux?

Mozilla retiró emSign ECC Root CA - G3 de su biblioteca NSS (versión 3.131.1) el 20 de octubre, y Ubuntu (USN-8944-1), Debian (DSA-6572-1) y Alpine publicaron paquetes ca-certificates sin esa raíz. El boletín RHSB-2026-012 de Red Hat declara afectados RHEL 6 a 10 y potencialmente afectados OpenShift, OpenStack y los contenedores de sus productos basados en imágenes RHEL o UBI. Los contenedores de cada cliente deben reconstruirse cuando se actualice la imagen base.

A 22 de octubre, Red Hat no había publicado el paquete ca-certificates corregido para RHEL. Sí lo había hecho para sus Hardened Images, con un CVE nuevo (CVE-2026-114406) que califica de crítico, y había publicado Go 1.26.10 para RHEL 8, 9 y 10 con el CVE de Go (CVE-2026-111943), que califica de importante.

¿Por qué importan las firmas cruzadas de Sectigo?

Las firmas de Sectigo crean una cadena alternativa para cada intermedio, hasta sumar 16 certificados que bloquear según el script de Windows del rastreador. Sectigo las revocó el 19 de octubre, pero la revocación solo protege a quien la consulta. Su raíz se había retirado de Chrome y Firefox, aunque, según indica Sectigo en el informe de Mozilla, sigue en los programas de Microsoft y Apple.

Por eso la medida provisional de Red Hat desconfía de dos raíces a la vez, emSign ECC Root CA - G3 y Comodo AAA Services root, el nombre con que figura AAA Certificate Services en los almacenes de Linux. La solución de Red Hat advierte que también dejarán de validarse los certificados legítimos que dependan de esas raíces, y el aviso CIAD-2026-0050 del CERT-In indio hace la misma advertencia sobre la retirada de emSign ECC Root CA - G3.

¿Cómo se corrigen Java, Go, Node.js y Python?

El aviso de OpenJDK del 21 de octubre indica que, si el JDK lo proporciona una distribución Linux como Debian, Ubuntu, Fedora o RHEL, actualizar los certificados del sistema es suficiente. Los de FreeBSD y Homebrew deben actualizarse directamente. Los JDK independientes bloquean los intermedios con su lista blocked.certs y necesitan la versión nueva (CVE-2026-91403, CVSS 9,1).

Go publicó el 19 de octubre (20 en UTC) las versiones 1.27.3 y 1.26.10, que rechazan las cadenas con alguna de las ocho claves (CVE-2026-111943). Según The Hacker News, Go 1.25 y anteriores no reciben corrección. En Linux, Go lee el almacén del sistema, así que la actualización de ca-certificates ya lo protege, y para el filtro de claves, o en binarios que incorporan sus raíces, hay que recompilar con una versión corregida.

Node.js publicó el 21 de octubre las versiones 22.23.4, 24.22.1 y 26.12.1, y certifi, el paquete de raíces de Python, la versión 2026.10.19. Cada entorno virtual con su copia de certifi necesita la actualización.

¿Por qué nadie relacionó antes el fallo con las claves?

En el informe de este incidente, Mozilla recuerda otro de junio de 2025 (bug 1970728, abierto por Sectigo). Las listas de revocación de los seis intermedios TLS no superaban la verificación desde finales de mayo de 2025, desde el día 23 según una captura de Internet Archive que Mozilla cita con reservas.

eMudhra explica ahora que las había firmado con las claves originales, distintas de las que figuraban en los certificados, y que en junio de 2025 las volvió a firmar con las claves débiles. Aquel incidente se cerró sin que nadie relacionara el desajuste con la calidad de las claves, y Chrome pregunta ahora por qué eMudhra no detuvo entonces la operación.

Recuperar las claves, una vez detectado el problema, fue trivial. El informe de Mozilla indica que algunos agentes de IA lo consiguieron a partir de una instrucción sencilla, y The Hacker News recoge que el investigador Scott Helme obtuvo las ocho en menos de un segundo. eMudhra atribuye el hallazgo a técnicas "posiblemente asistidas por IA", mientras que Wayne explicó en el foro de Mozilla que usó tal cual la biblioteca paranoid_crypto de Google.

¿Qué deben hacer quienes presentan certificados de emSign ECC Root CA - G3?

Google pide sustituir de inmediato los certificados que encadenen a emSign ECC Root CA - G3 por otros de una jerarquía distinta. Chrome retirará esa raíz con la versión 43 de su almacén, prevista para el 27 de octubre. Mozilla la retiró de NSS el día 20, así que esos certificados ya fallan en los clientes con la lista de Mozilla actualizada, como Debian, Ubuntu, certifi o Node.js.

eMudhra calcula en el informe de Mozilla que unos 30.000 certificados deben migrar, el 97 % emitidos por ACME, el protocolo de emisión y renovación automáticas, y la empresa dejó de emitir bajo esa raíz el 20 de octubre. Según los datos de CT que cita Chrome, casi todos proceden de autoridades subordinadas de InCommon, el servicio de confianza de Internet2, el consorcio académico estadounidense.

La automatización simplifica el cambio, aunque con matices. Chrome advierte de que los clientes ACME sin la extensión ARI no sustituyen el certificado fuera de su ventana de renovación, y de que pasar de la raíz ECC G3 a la RSA G1 puede exigir cambios en los clientes. Donde los certificados se compran e instalan a mano, la migración exige localizar cada servicio, cada equipo de red y cada aplicación que los use.

¿Dónde más viven copias de las raíces en un servidor?

La confianza en las autoridades de certificación es una dependencia más del software, con su versión y su calendario de parches. Un servidor típico tiene varias copias, como la del sistema operativo, la de un JDK independiente, la que empaqueta Node.js, la que instala certifi en cada entorno de Python, la que lleva una aplicación Electron y la que se congeló en cada imagen de contenedor. Salvo la del sistema, ninguna aparece en la consola de parches, y el SBOM de una aplicación, si las recoge, las muestra como un paquete más, sin indicar qué raíces contienen.

¿Cómo comprobar la exposición sin interrumpir servicios?

La forma más fiable es preguntar al cliente. El rastreador ofrece servidores de prueba que presentan las cadenas con los intermedios comprometidos, directa y a través de Sectigo, y un error de certificado significa que el cliente ya los rechaza. La prueba debe lanzarse desde donde se ejecuta cada programa, dentro de su contenedor y con su entorno, y con cada intérprete (curl, Python, Node.js), porque cada uno puede usar un almacén distinto.

# Desde el equipo o la imagen a comprobar: 60 = rechazado (correcto), 0 = aceptado
for h in dv-g3b-emudhra dv-g3b-aaa-emudhra; do curl -sS -o /dev/null "https://$h.we-have-a-problem.com/"; echo "$h: $?"; done

# Python con el almacén del sistema y con certifi (el que usan requests y pip)
python3 -c "import socket,ssl; h='dv-g3b-emudhra.we-have-a-problem.com'; ssl.create_default_context().wrap_socket(socket.create_connection((h,443),timeout=10),server_hostname=h)" && echo ACEPTA || echo RECHAZA
python3 -c "import socket,ssl,certifi; h='dv-g3b-emudhra.we-have-a-problem.com'; ssl.create_default_context(cafile=certifi.where()).wrap_socket(socket.create_connection((h,443),timeout=10),server_hostname=h)" && echo ACEPTA || echo RECHAZA

# Node.js
node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', r => { console.log('ACEPTA'); r.destroy(); }).on('error', e => console.log('RECHAZA', e.code))"

# Binarios Go: versión con la que se compilaron (corregido: go1.26.10, go1.27.3 o posterior)
go version ./binario

El segundo bloque comprueba si cada almacén conserva las raíces afectadas.

# RHEL, Fedora y derivados (p11-kit): sin salida = no se confía en ellas
trust list --filter=ca-anchors | grep -i -E "label: (emSign ECC Root CA - G3|Comodo AAA Services root)"

# Debian y Ubuntu
ls /etc/ssl/certs/ | grep -i -E "emSign_ECC_Root_CA_-_G3|Comodo_AAA_Services_root"

En Java y en los entornos de Python, la comprobación se hace sobre el almacén de cada uno.

# JDK 9 o posterior (en JDK 8: -keystore "$JAVA_HOME/jre/lib/security/cacerts")
# En un JDK corregido AAA sigue apareciendo, porque el bloqueo está en blocked.certs
keytool -list -v -cacerts -storepass changeit | grep -i -E "CN=emSign ECC Root CA - G3|CN=AAA Certificate Services"

# Python con certifi, con el intérprete de cada entorno virtual: 0 = raíz retirada, 3 = presente
grep -c "emSign ECC Root CA - G3" "$(python3 -m certifi)"

La presencia de la raíz no prueba por sí sola que el cliente acepte los intermedios, porque algunas correcciones, como las de Go y del JDK, los bloquean directamente. Otras raíces de emSign, como emSign Root CA - G1, no están afectadas, así que la búsqueda debe ser exacta. Un proxy que inspecciona TLS sustituye la cadena por la suya y altera el resultado de curl, y una salida distinta de 60 o 0 puede deberse a la red.

Para priorizar sirven las tres condiciones que fija Red Hat, un cliente que confíe en los intermedios, un atacante con una de las claves y capacidad de interceptar la conexión. Las claves son públicas desde el 20 de octubre, así que la tercera condición decide. Los primeros candidatos son los programas que salen a Internet desde redes que la organización no controla, como portátiles en itinerancia, agentes de actualización, integraciones con API de terceros y ejecutores de CI/CD. La medida provisional de eliminar raíces enteras debe probarse antes en un entorno controlado, porque corta también conexiones legítimas.

¿Qué controles funcionaron y qué supuestos fallaron?

Funcionaron los controles que no dependen de que alguien actúe, como la revocación distribuida por el fabricante y la exigencia de CT. Para lo que viene ahora parten con ventaja quienes emiten por ACME y quienes reconstruyen sus imágenes de contenedor de forma periódica desde la integración continua, porque la actualización de ca-certificates llega con la rutina. La vigilancia de los registros CT de los dominios de la organización entra en la misma lista, y este mes los datos de CT permitieron a Google localizar los certificados obtenidos tras el secuestro de los ccTLD .gh, .sl y .as.

Fallaron también supuestos habituales, como que actualizar el sistema operativo actualiza la confianza de todo lo que corre encima y que una imagen base estable puede pasar meses sin reconstruirse. La renovación manual de certificados deja de ser un trabajo administrativo menor cuando una raíz sale de Chrome con una semana de aviso y de NSS el mismo día del anuncio.

El bastionado de sistemas debería fijar dónde vive cada copia de las raíces y quién la mantiene, y la gestión de la superficie de ataque debería cubrir los certificados que presentan los servicios públicos. Ese inventario es el mismo que exige la transición a la criptografía poscuántica, que obliga a saber qué algoritmos, raíces y bibliotecas usa cada sistema y a poder cambiarlos sin reescribir aplicaciones.

El caso ilustra además una de las lecciones de la cadena de suministro digital, porque los errores de un tercero de confianza llegan a todos los que confían en él. Los procesos de DevSecOps deberían tratar las raíces como una dependencia más, expuesta como las demás a un ataque a la cadena de suministro.

¿Se sabe si alguien usó las claves?

No hay pruebas de explotación a 22 de octubre de 2026. La ausencia de estos intermedios en CT protege a los clientes que aplican esa comprobación. Contra el resto, un uso discreto desde abril de 2025, y con más facilidad desde que las claves se publicaron el 20 de octubre, no dejaría rastro público.

Chrome ha planteado a eMudhra doce preguntas sobre la comunicación a los clientes, la migración, el incidente de 2025 y una lista de revocación mal firmada de una raíz G1 publicada el 14 de octubre, y revisará si la otra raíz de la empresa en su almacén, emSign Root CA - G1, debe seguir. Mozilla pidió el detalle del hardware, y otro participante reclama el script de generación y las actas de la ceremonia. En India, el CERT-In publicó su aviso y el Ministerio de Electrónica y Tecnologías de la Información (MeitY) ha abierto una investigación, según The Hacker News.

La próxima retirada de una raíz obligará a responder la misma pregunta: en qué raíces confía cada programa. El inventario que la responde es el que permite aislar el problema mientras llegan las correcciones de los proveedores.

Este análisis se basa en información pública de Google, Mozilla, Red Hat, OpenJDK, eMudhra y los medios citados, disponible a 22 de octubre de 2026, y puede cambiar a medida que avance la investigación. Los comandos son orientativos para inventario y comprobación y deben revisarse y probarse en un entorno controlado antes de usarlos en producción. Las medidas que eliminan raíces de confianza pueden interrumpir conexiones legítimas.