eMudhra: 8 claves CA comprometidas y qué actualizar

¿Qué pasó con los certificados de eMudhra?

El 17 de octubre un investigador reportó a los root programs que las claves privadas de ocho certificados intermedios de la autoridad certificadora india eMudhra estaban comprometidas. La confirmación pública llegó el 20 de octubre, cuando Mozilla y el Chrome Root Program de Google dieron por válido el hallazgo.

El problema de fondo es de alcance: esas claves encadenan a raíces en las que confían Mozilla, Microsoft, Apple y Chrome, y por extensión buena parte de los trust stores que dependen de ellas. Cualquiera que tenga una de esas claves puede emitir un certificado válido para el dominio que quiera, y el navegador lo va a aceptar sin chistar.

Los ocho certificados afectados son EM DV TLS CA - G3B y G3C (validación de dominio), EM OV TLS CA - G3B y G3C (validación de organización), EM EV TLS CA - G3B y G3C (validación extendida) y EM OV CS CA - G3B y G3C (firma de código). Los seis de TLS fueron emitidos por emSign Root TLS CA - G3 y encadenan a emSign ECC Root CA - G3. eMudhra vende certificados bajo la marca emSign a través de sociedades en India, Estados Unidos y Países Bajos.

Hay un dato que baja bastante la temperatura: según el Chrome Root Program, ningún certificado TLS que encadene a los seis intermedios de uso web había quedado registrado en los logs de Certificate Transparency antes del bloqueo. Eso significa que ninguno pudo haber sido aceptado por defecto en Chrome ni en cualquier navegador que exija registro CT.

¿Por qué una clave intermedia comprometida es tan grave?

Un certificado intermedio es el eslabón que está entre la raíz y el certificado final de tu dominio. Existe justamente para aislar líneas de negocio y métodos de validación, y para poder rotar tecnología sin tocar la raíz. El detalle es que el navegador confía en el intermedio exactamente igual que en la raíz.

Por eso la respuesta de los root programs fue de horas, no de días. Chrome recibió el reporte a las 18:05 UTC del 17 de octubre y a las 19:45 UTC ya tenía un CRLSet bloqueando los seis intermedios de TLS. Mozilla lo recibió a las 20:06 UTC y a las 22:59 UTC había empujado el bloqueo OneCRL a las instalaciones de Firefox con configuración estándar. Apple bloqueó el 19 de octubre y Microsoft el 20. eMudhra, por su parte, revocó los ocho certificados.

El bloqueo de Chrome matchea por clave pública y no por certificado, así que también alcanza a las copias cross-signed por Sectigo bajo su raíz AAA Certificate Services. Mozilla removió emSign ECC Root CA - G3 de NSS el 20 de octubre, y Chrome anunció que hará lo mismo en la versión 43 de su root store mientras revisa el estado de la otra raíz de eMudhra en su lista, emSign Root CA - G1.

El problema es todo lo que no es un navegador. Los navegadores reciben las revocaciones empujadas; muchísimos otros programas que validan TLS no consultan datos de revocación y siguen confiando en una cadena hasta que cambia su código o su bundle de raíces. Ahí entran los binarios de Go, todo lo que use el bundle de certifi de Python, las distribuciones de Linux, los contenedores Docker y los dispositivos IoT.

Filippo Valsorda, mantenedor de los paquetes de criptografía de la librería estándar de Go, lo puso en términos crudos ante Ars Technica: esto va a ser un trabajo de limpieza masivo, más grande que Heartbleed, con una cola muy larga de dispositivos IoT, contenedores Docker, máquinas Linux olvidadas y herramientas de línea de comandos sin mantenimiento que embarcan su propia copia de las raíces.

¿Qué software necesita actualizarse ahora?

Estos son los parches publicados y su estado, según el relevamiento de The Hacker News:

• Go 1.27.3 y 1.26.10: rechaza cualquier cadena que contenga una de las ocho claves (CVE-2026-111943). Requiere recompilar el binario; 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: trae el bloqueo OneCRL para instalaciones que no pueden recibir Remote Settings (CVE-2026-113470).
• NSS 3.131.1: elimina emSign ECC Root CA - G3 de la lista de confianza.
• Python certifi 2026.10.19: saca emSign ECC Root CA - G3 del bundle.
• Rust webpki-roots 1.0.10: elimina la misma raíz.
• Homebrew ca-certificates 2026-09-25_1: excluye emSign ECC Root CA - G3, emSign Root TLS CA - G3 y AAA Certificate Services por clave pública.
• Node.js y Composer ca-bundle: todavía pendientes.

En el ecosistema Python, el artículo original de Simon Willison confirma que ya salieron uv 0.13.4, pip 26.2.2 y certifi 2026.10.19 con listas de certificados actualizadas.

Ojo con un efecto secundario: tres de los fixes funcionan eliminando raíces en lugar de bloquear las claves. Eso corta también todos los certificados legítimos que encadenen a esas raíces. Mozilla advirtió que algunos servidores van a quedar inaccesibles para usuarios de su trust list que no usen Firefox hasta que migren a nuevas cadenas de certificados.

¿Qué significa esto para tu startup?

Si tu producto corre sobre Linux, Go o Python, este incidente te toca aunque no uses eMudhra. La ventana de exposición no se cierra con un parche en tu laptop: se cierra cuando actualizas todas las copias del trust store que tu infraestructura usa en producción.

Acciones concretas para esta semana:

• Actualiza el paquete de CA del sistema operativo. En Debian y derivados, corré sudo dpkg-reconfigure ca-certificates, elegí la opción de preguntar y desmarcá las entradas de emSign. En sistemas con certctl, como NetBSD, el comando es certctl untrust sobre los archivos de emSign. Después verificá con un loop de curl contra los subdominios de prueba que publica el sitio de seguimiento del incidente: si ves el mensaje de conexión exitosa, el cambio no tomó.
• Recompila y redesplegá los binarios de Go. El filtro vive en la librería estándar y no tiene setting para desactivarlo, así que un binario viejo sigue confiando en las claves comprometidas hasta que lo recompiles con la versión parcheada. Revisá también las imágenes base de tus contenedores y los runners de CI, que suelen quedar fuera del ciclo de actualización.
• Subí las dependencias del stack Python. Actualizá certifi, pip y uv en tus entornos y en tus pipelines. Si tenés servicios que embarcan su propio bundle de raíces, ese bundle es el que importa, no el del sistema.
• Inventariá lo que no actualizás nunca. Dispositivos IoT, appliances, herramientas internas de línea de comandos y máquinas virtuales olvidadas son exactamente la cola larga de la que habla Valsorda. Si no sabés cuántas copias de un trust store tenés, ese es el primer problema a resolver.

Como endurecimiento de mediano plazo, vale la pena revisar tus registros CAA en DNS. Un registro CAA declara qué autoridades pueden emitir certificados para tu dominio y obliga a las CAs que cumplen con las Baseline Requirements del CA/Browser Forum a consultarlo antes de emitir. No te protege de una CA comprometida que decida ignorarlo, pero reduce la superficie de emisión no autorizada, según la guía técnica de CaptainDNS.

Antecedentes: DigiNotar y Symantec ya lo advirtieron

Este tipo de incidente no es nuevo, y la historia muestra que el costo para la CA puede ser terminal. En 2011, la autoridad holandesa DigiNotar fue comprometida y los atacantes emitieron más de 500 certificados fraudulentos, incluido un wildcard para dominios de Google, usados para interceptar tráfico de ciudadanos iraníes. DigiNotar perdió la confianza de los navegadores y terminó en bancarrota.

Entre 2015 y 2017, una serie de emisiones no conformes de Symantec, incluyendo certificados de prueba para dominios de terceros sin autorización, llevó a Google y Mozilla a planificar la desconfianza de su infraestructura heredada. El negocio de CA terminó vendido a DigiCert. La lección que se repite es la misma: basta una falla en una sola CA confiable para comprometer cualquier dominio.

Conclusión

El incidente de eMudhra es un recordatorio incómodo de que la seguridad de tu producto no depende solo de tu código. Depende de una cadena de confianza distribuida en la que confías por defecto y que rara vez auditás.

La buena noticia es que los root programs reaccionaron en horas y que no hay evidencia de certificados fraudulentos en los logs de Certificate Transparency. La mala es que la parte difícil recién empieza: actualizar distribuciones de Linux, contenedores, binarios compilados y dispositivos embebidos es un trabajo largo, y cada copia de un trust store que quede sin actualizar es una puerta abierta. Si tu equipo todavía no tiene un inventario de dónde vive su lista de certificados confiables, este es el momento de construirlo.

Fuentes

• eMudhra Intermediate CA Compromise - Simon Willison (fuente original)
• Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software - The Hacker News
• The Internet goes on high alert after discovery of 8 compromised TLS certs - Ars Technica
• eMudhra incident compromises eight CA certificates - heise online
• CAA DNS record: the complete, practical guide - CaptainDNS