Ocho claves privadas y un mensaje firmado: el caso eMudhra
El 17 de octubre, un investigador al que Mozilla acredita solo como Wayne firmó el mensaje 'We have a problem here - Wayne' con cada una de las ocho claves privadas de certificados intermedios de eMudhra, una autoridad certificadora (CA) con sede en India que vende certificados bajo la marca emSign. No era una advertencia teórica: la firma probaba que tenía las claves en la mano. Quien controle una clave intermedia puede emitir un certificado que cualquier navegador aceptará como válido para cualquier dominio del mundo.
Tres días después, el 20 de octubre, Chrome, Firefox, Apple y Microsoft ya habían bloqueado los ocho certificados. Y, según The Hacker News, ningún certificado encadenado a los seis intermedios de uso web había quedado registrado en los CT logs antes del bloqueo de Chrome. Esos registros públicos son la trazabilidad de todos los certificados confiables que se emiten. Hasta ahora no hay evidencia de uso malicioso.
El problema es que la parte visible del ecosistema TLS es la más fácil de arreglar.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días¿Qué certificados quedaron comprometidos?
El desglose, según el detalle publicado por The Hacker News, es el siguiente:
- TLS domain validated: EM DV TLS CA - G3B (operada por eMudhra BV, Países Bajos) y EM DV TLS CA - G3C (eMudhra Inc, Estados Unidos)
- TLS organization validated: EM OV TLS CA - G3B y EM OV TLS CA - G3C
- TLS extended validation: EM EV TLS CA - G3B y EM EV TLS CA - G3C
- Code signing: EM OV CS CA - G3B y EM OV CS CA - G3C
Los seis de TLS cuelgan de emSign Root TLS CA - G3 y encadenan a emSign ECC Root CA - G3, una raíz presente en los almacenes de confianza de Chrome y Apple y, hasta el mismo 20 de octubre, también en el de Mozilla. Además, cada uno de los ocho existe como una segunda copia con la misma clave pública, firmada de forma cruzada por Sectigo bajo su raíz AAA Certificate Services.
Chrome no necesitó bloquear los dos de code signing: su verificador TLS no construye una ruta de confianza a través de un intermedio restringido a firma de código. Sí bloqueó los seis de web, y como su lista de revocación (CRLSet) hace match sobre la clave pública y no sobre el certificado, también neutralizó las copias cross-signed.
¿Por qué actualizar el navegador no alcanza?
Los navegadores se protegen solos porque reciben las listas de revocación por push. Chrome tenía el bloqueo activo a las 19:45 UTC del 17 de octubre, poco más de hora y media después de recibir el reporte. Mozilla completó su OneCRL para instalaciones estándar a las 22:59 UTC, menos de tres horas después, sin necesidad de actualizar ni reiniciar Firefox. Apple bloqueó los certificados el 19 y Microsoft el 20.
El resto del ecosistema no funciona así. Muchísimos programas que validan TLS, desde binarios de Go hasta cualquier cosa que use el bundle certifi de Python, no consultan datos de revocación: siguen confiando en una cadena hasta que cambia el código o el bundle de raíces. De ahí la advertencia de Filippo Valsorda, ingeniero de criptografía y maintainer de las librerías criptográficas de la librería estándar de Go, a Ars Technica: esto será un trabajo de limpieza masivo, más grande que Heartbleed, con una cola larguísima de dispositivos IoT, contenedores Docker, máquinas Linux olvidadas y herramientas de línea de comandos sin mantenimiento que traen su propia copia de las raíces.
¿Qué software ya está parcheado y qué queda pendiente?
Estos son los arreglos publicados hasta ahora, según el relevamiento de The Hacker News:
- Go 1.27.3 y 1.26.10 (CVE-2026-111943): rechaza cualquier cadena que contenga una de las ocho claves. Requiere recompilar. Go 1.25 y anteriores quedaron fuera de soporte y no reciben el fix.
- Firefox 158.0.1, ESR 115.43.1 y ESR 153.5.1 (CVE-2026-113470): llevan la lista de bloqueo para instalaciones que no pueden recibir Remote Settings.
- NSS 3.131.1: elimina emSign ECC Root CA - G3 de la lista confiable.
- Python certifi 2026.10.19, Rust webpki-roots 1.0.10 y Homebrew ca-certificates 2026-09-25_1: sacan raíces enteras del bundle.
- Node.js y Composer ca-bundle: cambios en borrador o abiertos, todavía pendientes.
Tres de esos parches funcionan quitando raíces, no bloqueando claves. El efecto secundario es que también cortan todo certificado legítimo que encadene a esas raíces. Mozilla, que aplicó el mismo cambio en NSS, advirtió que algunos servidores quedarán inaccesibles para usuarios de su lista de confianza que no usen Firefox, hasta que migren a cadenas nuevas.
Sobre el origen: cómo salieron las claves de eMudhra, cuándo y si alguien más las tiene sigue sin respuesta. El repositorio de servicios de confianza de la CA no tenía ningún aviso del incidente al 20 de octubre, según The Hacker News. Chrome anunció que eliminará esa raíz en la versión 43 de su root store y que revisa el estado de la otra raíz de eMudhra que tiene listada, emSign Root CA - G1.
El antecedente: DigiNotar y por qué esta vez la industria respondió en horas
En 2011, la CA holandesa DigiNotar emitió 531 certificados falsos tras una intrusión, según el recuento que publicó Slate. Uno de ellos era un certificado comodín para Google que se usó en ataques man-in-the-middle contra usuarios iraníes: unas 298.140 direcciones IP únicas se vieron afectadas y el 95% de ellas estaba en Irán. El gobierno holandés intervino la empresa y DigiNotar terminó en bancarrota ese mismo septiembre.
La diferencia con lo de eMudhra está en los tiempos. DigiNotar tardó semanas en reconocer el problema y su remedio exigió actualizar navegadores con la información hardcodeada. Aquí, entre el reporte y el bloqueo efectivo pasaron menos de cuatro horas en dos navegadores, y la revocación llegó sin que el usuario tocara nada. Eso es, en buena medida, herencia de DigiNotar: la industria construyó después Certificate Transparency, el pinning y listas de revocación centralizadas como OneCRL y CRLSet.
¿Qué significa esto para tu startup?
La pregunta que importa no es si Chrome bloqueó las claves. Es si tu infraestructura las está usando en algún lugar donde nadie mira.
- Revisa si dependes de certificados de emSign o de Sectigo AAA. Si tu sitio, tu API o tu app móvil usan un certificado emitido bajo esas cadenas, tienes que rotarlo. Pídelo explícitamente a tu proveedor o a tu CA; no asumas que un aviso proactivo va a llegar.
- Audita lo que no es un navegador. El riesgo real vive en el tráfico servidor a servidor: microservicios en Go, funciones serverless, workers en Python con certifi, contenedores Docker. Ahí no hay push de revocación. Recompila con las versiones parcheadas y actualiza los bundles de raíces antes de tu próximo deploy.
- Prueba en staging los parches que quitan raíces. Si actualizas certifi, webpki-roots o el bundle de Homebrew, algunas conexiones legítimas pueden empezar a fallar contra servidores que aún no migraron de cadena.
- Monitorea los CT logs de tus dominios. Es gratis y es la única forma de enterarte si alguien emite un certificado a tu nombre. Es una tarea de minutos con las herramientas de monitoreo de logs que ya existen.
- Trata tu CA como lo que es: un proveedor crítico. Un incidente en una CA que no elegiste directamente puede romper tu producto. Vale la pena saber en qué cadenas confía hoy tu stack, aunque nunca hayas comprado un certificado a esa CA.
Conclusión
El incidente de eMudhra no es una catástrofe en curso: no hay certificados falsos detectados y los navegadores hicieron su trabajo en horas. Pero es un recordatorio de que la confianza en Internet está tercerizada y de que tú solo controlas una parte del sistema. Los navegadores y las apps grandes ya están cubiertos; la cola larga de servidores, contenedores y dispositivos embebidos es donde este tipo de incidentes se cobra su tiempo. La acción útil para un founder no es alarmarse, es saber con precisión qué cadenas de confianza corren dentro de su propio producto y tener un plan para rotarlas.
Fuentes
- The Internet goes on high alert after discovery of 8 compromised TLS certs (fuente original)
- Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software
- Protecting Firefox users following the compromise of eMudhra intermediate certificates
- How the 2011 hack of DigiNotar changed the internet's infrastructure
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
