Chrome retira la raíz de eMudhra que avaló claves privadas de un byte

Google publicará el martes 27 de octubre de 2026, por la mañana en horario del Pacífico, la versión 43 del Chrome Root Store, que elimina emSign ECC Root CA G3, la raíz de eMudhra que firmó ocho certificados intermedios cuyas claves privadas podía calcular cualquiera. Unos 30.800 certificados TLS vigentes cuelgan de esa raíz y dejarán de funcionar en Chrome, aunque ninguno de ellos se emitió con las claves comprometidas.

Ocho claves P-384 que caben en un byte

Una clave privada de curva elíptica P-384 debería ser un número aleatorio de 384 bits. Las de los ocho intermedios de eMudhra eran enteros menores que 256. Scott Helme lo resumió en su análisis del 20 de octubre con una frase que resume el caso, «One of eMudhra's certificate authority private keys is the number 4» (una de las claves privadas de la autoridad de certificación de eMudhra es el número 4). El método para recuperarlas no requiere ninguna técnica de criptoanálisis. Basta con multiplicar el punto generador de la curva por 1, por 2, por 3 y así sucesivamente hasta que el resultado coincida con la clave pública publicada en el certificado. En el peor caso son 255 multiplicaciones, y Helme sacó las ocho en menos de un segundo con un portátil.

La tabla de Helme muestra los valores recuperados. Seis intermedios son de TLS (DV, OV y EV, cada uno en dos variantes, G3B para eMudhra BV y G3C para eMudhra Inc) y dos son de firma de código. El más débil es EM OV TLS CA G3C, con clave 4. Con cualquiera de los seis de TLS, un atacante puede firmar un certificado válido para cualquier dominio y hacer un ataque de intermediario sin que el cliente vea un aviso, el escenario clásico de la intercepción de tráfico SSL pero sin necesidad de instalar una CA propia en el equipo de la víctima. Con los dos de firma de código, que confiaba Microsoft, se puede firmar software que Windows daría por legítimo.

El origen está en una ceremonia de generación de claves del 30 de abril de 2025 en la que eMudhra creó 24 CA subordinadas. Según la explicación de la propia empresa, un paso de envoltura y desenvoltura de claves en el HSM generó un segundo juego de claves débiles con etiquetas parecidas a las buenas, y alguien eligió las equivocadas para las peticiones de firma. En su disculpa del 26 de octubre, eMudhra lo reduce a una línea, «A script error resulted in issuing CA's with weak keys» (un error de script provocó la emisión de CA con claves débiles). En la actualización del 21 de octubre todavía decía que no había confirmado la causa exacta, y las dos versiones no encajan del todo.

El detalle que amplió el alcance es la firma cruzada. Los ocho intermedios tienen copias con la misma clave pública firmadas en mayo de 2025 por AAA Certificate Services, la antigua raíz de Comodo que hoy gestiona Sectigo. Esa raíz está en almacenes de confianza mucho más antiguos que los de eMudhra, incluidos los de sistemas y dispositivos que nunca incorporaron las raíces emSign. Chrome y Firefox dejaron de confiar en AAA para webs en abril de 2025, así que en ellos la copia cruzada no añadía riesgo. En otros clientes sí lo hacía.

De la prueba firmada de Wayne al bloqueo de Firefox en tres horas

El aviso llegó el sábado 17 de octubre. Un investigador que firma como Wayne escribió a los programas raíz con una prueba de control de las ocho claves, un mensaje firmado con cada una de ellas. El bug 2083449 de Mozilla recoge la secuencia minuto a minuto, y Mozilla anota allí que recuperó las claves por su cuenta a las 21:48 UTC, sin conocer el método del investigador, «confirming the key generation process was flawed and is trivial to exploit» (lo que confirma que el proceso de generación de claves era defectuoso y trivial de explotar).

La página eMudhra Intermediate CA Compromise, que publicó Dennis Jackson el 20 de octubre y mantienen varios colaboradores, reúne la prueba de Wayne con los comandos OpenSSL para verificarla y un comprobador de cadenas. En la captura se ve el mensaje firmado y la fecha de bloqueo en cada plataforma. Hay una discrepancia con parte de la cobertura posterior, que sitúa el bloqueo de Apple el 19 de octubre. La página de Jackson y BleepingComputer lo fechan el 22, y es la fecha que usamos.

Nadie ha documentado abusos. Cisco Talos no había visto incidentes con estos certificados a las 14:00 UTC del 21 de octubre, y Cloudflare escribió que su revisión no encontró explotación activa en sus servicios. Chrome añade un dato que limita el riesgo para el navegador. Ningún certificado TLS encadenado a los seis intermedios se registró en Certificate Transparency antes del bloqueo, y como Chrome, Firefox, Edge y Safari exigen ese registro, un certificado falso emitido en silencio no habría pasado en ellos. El Chrome Root Program revisó además el resto de CA de su almacén y, según su mensaje del 20 de octubre en la lista dev-security-policy, «found no other instances of this failure mode» (no encontró otros casos de este tipo de fallo).

Qué rompe la retirada de emSign ECC Root CA G3 en Chrome

El bloqueo de los intermedios no tumbó ninguna web legítima, porque, según eMudhra, ninguno había emitido certificados finales. La retirada de la raíz sí lo hará. Google cuenta en su anuncio del 20 de octubre unos 30.800 precertificados vigentes que encadenan a emSign ECC Root CA G3 con datos de Certificate Transparency del 21 de octubre, y casi todos pertenecen a dos intermedios de InCommon, el servicio de Internet2 para universidades de Estados Unidos. eMudhra describe el impacto como algo «contained to a single customer ecosystem in the United States» (limitado a un único ecosistema de clientes en Estados Unidos).

El recuento de CertKit sobre InCommon da la medida del trabajo pendiente. La tarde del 21 de octubre, 43 de 57 grandes universidades seguían con certificados vigentes en la cadena ECC, 5.042 en total, con umn.edu a la cabeza con 916. La emisión de certificados RSA de eMudhra para InCommon pasó de unos 600 diarios a 3.660 ese mismo día, y de 1.023 sustituciones observadas en siete horas, 967 fueron a la cadena RSA de eMudhra y 56 a Let's Encrypt. CertKit recuerda dos trampas para quien migre. Un registro CAA que solo autorice emsign.com impide que otra CA emita, y los balanceadores y appliances que no gestiona ACME hay que actualizarlos a mano, algo que ya contamos con el caso de la rotación de certificados en F5.

Estos son los dominios con más certificados todavía en la cadena ECC según ese recuento de CertKit.

En España no hemos localizado en el momento de escribir esta noticia ningún aviso de INCIBE-CERT ni del CCN-CERT sobre el caso. El certificado de una web española rara vez encadenará a emSign ECC Root CA G3, así que el trabajo aquí se concentra en el lado cliente.

Almacenes de confianza fuera del navegador que siguen aceptando las claves

Los navegadores se arreglaron con un cambio remoto, y Cloudflare lo describe como un ajuste que se hizo «with a flip of a switch» (con solo pulsar un interruptor). El resto del software que valida TLS con su propia lista de raíces no recibe CRLSet ni OneCRL y depende de una actualización. Go, que registró el problema como CVE-2026-111943, usa en la mayoría de plataformas el almacén del sistema, pero añadió en crypto/x509 una lista de bloqueo con los hashes de las ocho claves públicas para los casos en que ese almacén no se actualice. Node.js hizo lo mismo en sus versiones 26.12.1, 24.22.1 y 22.23.4 del 21 de octubre. Quien esté revisando estos días sus despliegues de Node.js por el fallo Node2Shell puede incluir esta comprobación en la misma pasada. La lista de Talos sobre los intermedios incluye la huella SHA-256 y el número de serie de cada uno.

Para saber si un servidor propio o de un proveedor encadena a eMudhra, basta con pedir la cadena completa y buscar el emisor. Este comando muestra los sujetos y emisores de cada certificado de la cadena.

openssl s_client -connect ejemplo.com:443 -servername ejemplo.com -showcerts </dev/null 2>/dev/null \
  | grep -E "^ *[0-9]+ s:|^ *i:" | grep -iE "emsign|emudhra|AAA Certificate Services"

El orden de trabajo que proponemos va de más a menos urgente.

1. Actualiza Go a 1.27.3 o 1.26.10 y Node.js a 26.12.1, 24.22.1 o 22.23.4 en servidores, imágenes de contenedor y runners de CI. Las ramas de Go 1.25 y anteriores no reciben el arreglo.
2. Sube certifi a 2026.10.19 en los entornos Python, Composer ca-bundle a 1.6.0 o 1.4.16 en PHP y webpki-roots a 1.0.10 en Rust, porque estas librerías llevan su propia copia de las raíces.
3. Aplica USN-8944-1 y USN-8944-2 en Ubuntu y DSA-6572-1 en Debian. En Red Hat Enterprise Linux aún no hay paquete, y el boletín RHSB-2026-012 describe un bloqueo manual de emSign ECC Root CA G3 y de AAA Certificate Services para RHEL 7 y posteriores.
4. Actualiza el cliente de Cloudflare One (WARP), la app 1.1.1.1 y cloudflared a 2026.10.2, y vuelve a desplegar los contenedores con la imagen corregida.
5. Revisa proxies, balanceadores, clientes VPN, equipos IoT y appliances con almacenes de raíces embebidos, que son los que menos se actualizan, y pide al fabricante la versión corregida.
6. Si una aplicación empieza a fallar la verificación TLS tras actualizar, cambia el certificado del servidor. Cloudflare lo advierte con una frase directa, «It's important to not resolve these errors by disabling verification» (no hay que resolver estos errores desactivando la verificación).

En los equipos Linux y en las imágenes de contenedor conviene comprobar también qué raíces quedan en el almacén del sistema y en las copias que llevan las librerías. Si alguna de estas búsquedas devuelve resultados después de actualizar, ese almacén sigue confiando en la raíz retirada. Los comandos de Linux para ciberseguridad que repasamos hace tiempo sirven para automatizar la búsqueda en un parque grande.

# Almacén del sistema (Debian, Ubuntu y derivadas)
awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' \
  /etc/ssl/certs/ca-certificates.crt | grep -iE "emsign|AAA Certificate Services"
# Copia de certifi en el entorno Python activo
python3 -c "import certifi; print(certifi.__version__, certifi.where())"
grep -c "emSign ECC Root CA - G3" "$(python3 -c 'import certifi; print(certifi.where())')"
# Almacenes Java
keytool -list -cacerts -storepass changeit 2>/dev/null | grep -i emsign

Hay un riesgo adicional. CertKit cuenta que mitmproxy añadió el 21 de octubre una opción --emudhra que firma certificados para cualquier sitio con una de las claves comprometidas. Es una herramienta pensada para probar clientes, y también rebaja a cero el esfuerzo de quien quiera interceptar tráfico de software que todavía confíe en esos intermedios. Las buenas prácticas de TLS de validación estricta de la cadena no sirven de nada si el almacén de raíces que se usa para validarla está desfasado.

Lo que eMudhra no ha aclarado tras su salida del negocio TLS

El 22 de octubre, el consejo de eMudhra decidió abandonar el negocio global de certificados SSL/TLS, que según la empresa supone el 1 % de sus ingresos. Mantendrá la revocación y los servicios de estado hasta que caduquen o se sustituyan todos los certificados emitidos, y ofrecerá sustitutos gratuitos a través de socios que no ha nombrado. Sus firmas digitales, eSign y plataformas de PKI empresarial quedan fuera del anuncio. El Chrome Root Program, por su parte, sigue estudiando si mantiene las demás raíces de eMudhra, entre ellas emSign Root CA G1.

La captura que publicó CertKit de la página de estado de eMudhra el 21 de octubre resume la comunicación de la empresa durante la semana, con un indicador de todos los sistemas operativos encima de un banner de incidencias. CertKit recoge también dos avisos previos sobre esa misma jerarquía. En junio de 2025 Sectigo informó de que las listas de revocación de los nuevos intermedios no superaban la verificación de firma, y eMudhra lo atribuyó a una configuración incorrecta de la clave de la CA. El 14 de octubre de 2026, tres días antes del informe de Wayne, una lista de revocación RSA volvió a fallar la verificación y se sustituyó unas 14 horas después sin informe de incidente.

En el blog vemos este caso como un fallo de proceso más que de criptografía. P-384 sigue siendo tan sólida como antes, del mismo modo que el debate sobre la criptografía post-cuántica da por hecho que la clave privada sale de una fuente de entropía decente. Una ceremonia de claves auditada y una comprobación trivial del tamaño efectivo de la clave antes de pedir la firma habrían bastado. Lo que queda abierto es el inventario de almacenes que nadie vigila, porque la raíz de Sectigo que firmó las copias cruzadas sigue en las listas de iOS 26 y macOS 26 y en muchos dispositivos que no reciben actualizaciones. Los intermedios están revocados, y eso solo protege a los clientes que consultan la revocación.