Claves de CA de eMudhra comprometidas: Go, Firefox y NSS publican parches

Las claves privadas de ocho certificados intermedios de eMudhra, una autoridad de certificación india, quedaron expuestas, confirmaron Mozilla y Google el 20 de octubre de 2026. Cualquiera que tenga esas claves podría emitir certificados HTTPS en los que los navegadores confiarían para sitios que no son suyos. Los navegadores bloquearon los certificados en cuestión de horas, pero muchas aplicaciones fuera del navegador siguen expuestas hasta que se actualicen.

Qué pasó con las claves de eMudhra

Una autoridad de certificación, o CA, avala sitios web firmando sus certificados. Las grandes CA firman a través de certificados «intermedios», que se sitúan entre su raíz y cada sitio web. Si se filtra la clave privada de un intermedio, un atacante puede crear un certificado de apariencia válida para cualquier dominio.

Un investigador comunicó las ocho claves a los fabricantes de navegadores el sábado 17 de octubre. Lo demostró firmando un mensaje con cada clave: «We have a problem here - Wayne.» (Tenemos un problema aquí - Wayne.) Seis de los intermedios emiten certificados de sitios web (TLS) y dos firman código de software, informa The Hacker News.

Las claves, además, eran débiles, según el investigador de seguridad Scott Helme. Cada una era un número diminuto, y él recuperó las claves privadas de los 16 certificados relacionados en menos de un segundo. Los intermedios datan de abril de 2025, así que cualquiera podría haber hecho lo mismo durante unos 17 meses. Helme cita la explicación de eMudhra: un fallo en un script creó un segundo par de claves débil, y el personal eligió el equivocado porque los nombres se parecían.

The Hacker News dice que se desconoce cómo salieron las claves de eMudhra y quién más las tiene. El análisis de Helme añade que no hay forma de saber si alguien las recuperó antes de ahora.

El 22 de octubre, eMudhra anunció que abandona por completo el negocio global de certificados SSL/TLS, como explica eMudhra abandona el negocio global de certificados SSL/TLS tras su fallo de claves débiles.

Con qué rapidez actuó cada empresa

Cuándo (UTC)	Acción
17 de octubre, 18:05	El programa de raíces de Chrome recibe el aviso
17 de octubre, 19:45	Chrome bloquea los seis intermedios TLS mediante CRLSet, su lista de revocación
17 de octubre, 20:06	Mozilla recibe el aviso
17 de octubre, 22:59	El bloqueo de OneCRL de Firefox llega a los usuarios con la configuración estándar
19 de octubre	Apple bloquea los certificados
20 de octubre	Microsoft los bloquea; salen versiones de Go, Firefox y NSS

Mozilla dice que Firefox no necesitó ninguna actualización ni reinicio para el bloqueo. También publicó Firefox 158.0.1, ESR 115.43.1 y ESR 153.5.1 para los usuarios cuya configuración personalizada detuvo las actualizaciones de OneCRL. NSS 3.131.1, la biblioteca de seguridad de Mozilla, elimina la raíz emSign ECC Root CA - G3, que firmó los intermedios. Chrome retirará la misma raíz en la versión 43 de Chrome Root Store.

Chrome no bloqueó los dos intermedios de firma de código, porque sus comprobaciones de sitios web nunca pasan por ellos. Chrome también dijo que revisó todas las demás CA de su almacén y que «no encontró otros casos de este modo de fallo». Ningún certificado de sitio web registrado se encadenaba a los seis intermedios TLS antes del bloqueo de Chrome, informa The Hacker News.

Por qué las aplicaciones fuera del navegador siguen en riesgo

Los navegadores reciben las listas de bloqueo automáticamente. La mayor parte del resto del software no comprueba la revocación en absoluto. Confía en una lista de CA incluida hasta que alguien publique una nueva.

Helme lo probó con un certificado falsificado para api.stripe.com. Con la configuración predeterminada, curl, Python y Node lo aceptaron en Linux y macOS. En Windows, la biblioteca criptográfica del sistema lo aceptó a menos que la comprobación de revocación estuviera activada.

Go necesitó un cambio de código por el mismo motivo, explica Cyber Kendra. Su verificador de certificados no lee las listas de bloqueo de los navegadores, así que los programas en Go confían en las claves hasta que se recompilan. Estas son las versiones corregidas que citan los distintos informes:

Software	Versión corregida
Go	1.27.3 y 1.26.10 (CVE-2026-111943); 1.25 y anteriores ya no tienen soporte
Firefox	158.0.1, ESR 115.43.1, ESR 153.5.1
NSS	3.131.1
Python certifi	2026.10.19
Rust webpki-roots	1.0.10
Electron	44.9.1, 43.8.1, 42.11.16

Qué significa para los desarrolladores

Los navegadores están cubiertos. Tus servidores, herramientas de compilación y contenedores probablemente no, hasta que los actualices.

• Recompila los servicios en Go. Un binario de Go lleva dentro sus comprobaciones de certificados. Recompila con Go 1.27.3 o 1.26.10 y vuelve a desplegar; actualizar solo la lista de CA de la máquina no ayuda.
• Actualiza las listas de CA incluidas. Actualiza certifi en proyectos de Python, webpki-roots en Rust y Electron en aplicaciones de escritorio. Reconstruye las imágenes de contenedor para que recojan el nuevo paquete del sistema. Las versiones de Python del 21 de octubre incluyen la corrección para instalaciones nuevas, como explica Python 3.15.1, 3.14.9 y 3.13.17 incluyen pip 26.2.2.
• Revisa tus propias cadenas. Si un proveedor o un servicio interno usa un certificado de eMudhra, averígualo antes de que desaparezcan las raíces. Pega un certificado en un decodificador de certificados y lee su campo de emisor.
• Activa las comprobaciones de revocación donde puedas. La prueba de Helme en Windows solo detectó el certificado falsificado con la comprobación de revocación activada. Trata esa opción como parte de tu configuración de TLS, no como un extra.