Las claves privadas de ocho certificados de CA intermedia de eMudhra, una autoridad certificante de India que opera con la marca emSign, quedaron comprometidas. El aviso llegó a Chrome y a Mozilla el 17 de octubre.
Los navegadores ya bloquean esos certificados. Pero buena parte del software que no consulta revocaciones necesita una actualización: Go publicó el 19 de octubre las versiones 1.27.3 y 1.26.10, y los programas tienen que recompilarse para quedar protegidos.
Qué pasó
Un investigador identificado como «Wayne» informó el compromiso a los programas de raíces de los navegadores. Para probarlo, firmó el mensaje «We have a problem here» con cada una de las ocho claves.
Dennis Jackson, ingeniero de criptografía de Mozilla, publicó las firmas y los certificados en ese sitio, junto con la lista de paquetes ya corregidos en distribuciones Linux y lenguajes.
Según The Hacker News, los ocho certificados afectados son:
- Seis intermedias TLS (validación de dominio, de organización y extendida, en sus variantes G3B y G3C), que emiten certificados para sitios web.
- Dos intermedias de firma de código (
EM OV CS CA - G3ByG3C).
Cada uno tiene además una copia con firma cruzada de Sectigo. Sectigo revocó esas copias el 19 de octubre, según el análisis de los registros de revocación publicado por fenko.nz.
Por qué es grave
Una CA intermedia es la que firma los certificados que presentan los sitios. Los navegadores y sistemas operativos confían en ella porque está firmada por una CA raíz que traen precargada.
Quien tenga la clave privada de una de las seis intermedias TLS puede emitir certificados válidos para cualquier dominio y suplantar sitios o servicios sin que el cliente lo note.
No se sabe cómo ni cuándo salieron las claves de eMudhra, ni si alguien además del investigador las tiene. Tampoco hay, por ahora, un informe de incidente público de la CA.
Un dato a favor: ninguna de las intermedias TLS registró certificados en Certificate Transparency (el registro público de certificados emitidos) antes del bloqueo de Chrome. Pero ese registro no puede probar que una clave robada no se haya usado sin registrar.
La respuesta de navegadores y proveedores
- Chrome: recibió el aviso a las 18:05 UTC del 17 de octubre y a las 19:45 UTC ya bloqueaba las seis intermedias TLS con una actualización de CRLSet. Además, va a quitar la raíz
emSign ECC Root CA - G3de su almacén. - Firefox: Mozilla completó el bloqueo vía OneCRL a las 22:59 UTC del 17 de octubre. Firefox 158.0.1 y las ESR 115.43.1 y 153.5.1, del 20 de octubre, lo incluyen para instalaciones que no reciben Remote Settings.
- Mozilla NSS: la versión 3.131.1 quitó la raíz
emSign ECC Root CA - G3. - Apple: bloqueó los certificados el 19 de octubre.
- eMudhra: revocó los ocho certificados.
El software que no consulta revocaciones
Muchos clientes TLS (librerías, runtimes, herramientas de línea de comandos) no consultan listas de revocación. Confían en el conjunto de raíces que traen o que leen del sistema, y siguen confiando hasta que ese conjunto o su código cambian.
Por eso Go lanzó una actualización urgente (CVE-2026-111943): el verificador de crypto/x509 rechaza cualquier cadena que pase por las ocho claves públicas, con el error x509: no valid chains built.
El filtro no se puede desactivar y aplica también cuando el programa define sus propias raíces de confianza. Solo protege a los binarios recompilados con las nuevas versiones.
Go 1.25 y anteriores ya no tienen soporte.
Filippo Valsorda, responsable de los paquetes criptográficos de Go, explicó que los almacenes de raíces de Linux no se mantienen lo suficiente como para que la revocación llegue a las aplicaciones, y que poner las claves en el código es por ahora la única opción.
Otros ecosistemas también se movieron:
- Python:
certifi2026.10.19 quitaemSign ECC Root CA - G3. - Rust:
webpki-roots1.0.10 quita la misma raíz. - Node.js: al 20 de octubre, el cambio que bloquea las ocho claves seguía en borrador.
Quitar una raíz completa también corta los certificados legítimos que dependen de ella. Mozilla advirtió que algunos servidores van a dejar de ser accesibles para clientes que usan su lista de raíces hasta que migren a otra cadena.
Qué conviene hacer
- Navegadores y sistemas operativos: actualizar. Firefox solo necesita acción si Remote Settings está deshabilitado por política o bloqueado en la red.
- Servicios en Go: recompilar con Go 1.27.3 o 1.26.10 y volver a desplegar.
- Python, Rust y contenedores: actualizar
certifi,webpki-rootsy el paqueteca-certificatesde las imágenes base, según los parches de cada distribución listados en el sitio de Jackson. - Proxies y equipos de inspección TLS: verificar con el fabricante si ya bloquearon las ocho intermedias y, si no, bloquearlas por el hash de la clave pública.
- Sitios con certificados emSign: si la cadena pasa por alguna de estas intermedias, obtener un certificado de otra cadena antes de que los clientes actualizados dejen de conectarse.
Es el segundo episodio de octubre que pone a prueba la confianza en HTTPS, después de los certificados falsos emitidos para dominios de Google tras el compromiso de tres dominios de país.
¿Saben cuántos almacenes de certificados tienen en producción?
Navegadores, runtimes, imágenes de contenedores, proxies: cada uno guarda su propia lista de en quién confiar.
¿Ya revisaron cuáles de los suyos siguen confiando en estas claves? Te leemos en los comentarios.
Fuentes
- Dennis Jackson: eMudhra, we have a problem
- The Hacker News: Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software
- The Hacker News: Go Issues Emergency Update Blocking Eight CA Keys
- fenko.nz: Eight eMudhra CAs Were Revoked for Compromise, and Nobody Has Said Why
- Ars Technica: The internet goes on high alert after discovery of 8 compromised TLS certs
