Certificado eMudhra comprometido: qué hacer ahora

En pocas palabras: Microsoft bloqueó los ocho certificados intermedios comprometidos de eMudhra el 20 de octubre de 2026, un día después que Apple (19 de octubre) y tres días más tarde que Firefox y Chrome, que actuaron horas después del reporte inicial del 17 de octubre.

El 17 de octubre de 2026, un investigador reportó que las claves privadas de ocho CA intermedias de eMudhra eran números menores a 256, cuando el estándar exige enteros aleatorios de 384 bits. Firefox y Chrome bloquearon esos certificados en horas; Apple lo hizo recién el 19 de octubre y Microsoft el 20 de octubre. Resultado: un certificado eMudhra comprometido puede dejar de ser confiable para tu navegador, pero seguir siendo válido para tu backend.

Un certificado eMudhra comprometido es cualquier certificado TLS o de firma de código que encadena a una de las ocho CA intermedias de eMudhra cuyas claves privadas se podían recuperar en milisegundos a partir del certificado público, según detalló el análisis técnico de Scott Helme. eMudhra es una autoridad certificadora cuyos roots emSign están instalados en los principales trust stores del mundo.

¿Qué pasó con las claves privadas de eMudhra?

Un investigador identificado como Wayne reportó, el sábado 17 de octubre, que podía recuperar la clave privada de ocho CA intermedias de eMudhra directamente desde el certificado público. Eso no debería pasar nunca.

Las ocho son claves elípticas en curva P-384. El valor privado d tiene que ser un número aleatorio de 384 bits, o sea, algo imposible de adivinar. Acá eran 47 bytes de ceros seguidos de un solo byte: 156, 230, 115, 56, 155, 4, 66 y 237. Con esos valores, recuperar la clave es cuestión de probar 1 × G, 2 × G, 3 × G hasta pegarle, como mucho 255 intentos. Helme recuperó las ocho en menos de un segundo en su laptop.

Seis de esas CA emiten certificados TLS (DV, OV y EV, en dos generaciones) y dos firman código. Todas se crearon en abril de 2025 y Sectigo las cross-firmó con su root AAA Certificate Services en mayo del mismo año. En el bug 2083449 de Mozilla, eMudhra explicó que un error en el script de la ceremonia de generación de claves creó un segundo par de claves más débil en el HSM. Como las etiquetas eran parecidas, alguien usó la clave equivocada para el CSR, y ese CSR terminó cross-firmado también. La propia eMudhra lo admite: “hubo errores humanos en múltiples pasos del proceso”.

¿Y nadie lo notó durante 17 meses? No. Según el incident page del caso, no hay registros en Certificate Transparency de estas intermedias emitiendo certificados maliciosos, así que los navegadores con CT estuvieron protegidos todo este tiempo. Lo que no está nada claro es qué pasó con el resto del ecosistema, el que no revisa CT.

¿Qué hicieron Firefox, Chrome, Apple y Microsoft?

Firefox bloqueó las ocho intermedias vía OneCRL el mismo 17 de octubre a las 22:59 UTC, sin necesidad de reiniciar el navegador. Chrome empujó un CRLSet esa misma noche. Apple siguió el 19 de octubre y Microsoft el 20. Complementá con diferencias clave entre Microsoft y GitHub.

El 20 de octubre, Mozilla dio un paso más fuerte: publicó NSS 3.131.1, que elimina por completo el root emSign ECC Root CA – G3 del trust store, según el comunicado oficial de seguridad de Mozilla. Chrome confirmó que hará lo mismo en Chrome Root Store v43. Mozilla, por ahora, no está removiendo el otro root de eMudhra, emSign Root CA – G1.

Ojo con la diferencia entre ambas acciones, porque confunden a mucha gente. Bloquear las intermedias comprometidas protege contra un ataque activo, pero no te rompe nada: según comentó eMudhra en el propio bug, solo una de las ocho (EM DV TLS CA G3C) llegó a producción. Eliminar el root G3 es otra historia completamente distinta, porque ahí sí deja de funcionar cualquier certificado legítimo que encadene a ese root, tengas o no un ataque en curso. eMudhra calcula que unos 30.000 certificados necesitan migrar, y el 97% llegó por ACME.

¿Cómo verificar si tu sitio usa un certificado eMudhra comprometido?

Corré este comando contra tu dominio y fijate si aparece algo con eMudhra o emSign en la cadena de certificados:

openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null \
| grep -E '^ *[0-9]+ s:|^ *i:' \
| grep -iE 'emsign|emudhra|EM (DV|OV|EV) TLS'

Si no te devuelve nada, tu cadena servida no menciona a eMudhra. Si ves emSign ECC Root CA - G3 o emSign Root TLS CA - G3 en cualquier línea, estás afectado. Tu servidor normalmente no envía el root, así que la línea del issuer de la intermedia superior es donde vas a encontrarlo.

Corré ese chequeo contra cada hostname real que termina TLS en tu infraestructura, incluidos los que están detrás de un balanceador o un CDN. El certificado que tenés guardado en el repo no es necesariamente el que tu edge sirve en producción. Después corré lo mismo contra las APIs de terceros que consumís: si un proveedor de pagos o un webhook corre sobre eMudhra, el problema también es tuyo. Sobre eso hablamos en cómo asegurar el acceso SSH a tus VMs.

¿Tus servicios backend siguen confiando en las claves comprometidas?

Sí, probablemente. Firefox, Chrome y Safari están cubiertos porque bloquean las intermedias y exigen Certificate Transparency. Tu worker de Python, tu servicio en Go, tu script de Node y tu runner de CI, en la mayoría de los casos, no hacen ninguna de las dos cosas.

Helme montó un servidor local con un certificado falso de api.stripe.com (sí, justo ese dominio) y probó qué pasaba. curl reportó “SSL certificate verify ok”. Python completó el handshake sin quejarse. Node devolvió authorized: true. Pasó en todas las máquinas Linux y macOS que probó, con la configuración por defecto. El incident page publica hosts de prueba que encadenan a través de EM DV TLS CA – G3B, y según el relevamiento técnico publicado el 21 de octubre, ambos comandos de prueba seguían devolviendo “STILL TRUSTED” el 22 de octubre, cinco días después del reporte inicial.

Estas son las ocho claves que había que recuperar para falsificar cualquiera de esos certificados (spoiler: ninguna tardó más de un segundo):

Intermedia	Tipo	Valor de d (clave privada)
EM DV TLS CA – G3B	TLS	156
EM DV TLS CA – G3C	TLS	230
EM EV TLS CA – G3B	TLS	115
EM EV TLS CA – G3C	TLS	56
EM OV TLS CA – G3B	TLS	155
EM OV TLS CA – G3C	TLS	4
EM OV CS CA – G3B	Firma de código	66
EM OV CS CA – G3C	Firma de código	237

Las versiones parcheadas ya están listadas en el incident page: NSS 3.131.1, certifi 2026.10.19, Go 1.27.3 y 1.26.10, Node.js 22.23.4, 24.22.1 y 26.12.1, Deno 2.9.8, rustls-webpki 0.103.16 y webpki-roots 1.0.10. Actualizar el sistema operativo no alcanza. Si tu contenedor se construyó el mes pasado, tenés que reconstruirlo, porque una imagen base actualizada no hace nada por un contenedor que ya existe.

¿Cómo migrar tu certificado fuera de eMudhra sin romper tu sitio?

Si el 97% de tus certificados llegó vía ACME, migrar es básicamente cambiar la URL del directorio ACME y volver a emitir. Con certbot, por ejemplo: Esto se conecta con lo que analizamos en qué certificación de Azure conviene según tu rol.

# si tenés registros CAA, agregá la nueva CA antes o va a rechazar la emisión
# example.com. CAA 0 issue "letsencrypt.org"
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory \
 -d example.com -d www.example.com --force-renewal

El orden importa. Agregá el registro CAA de la nueva CA, emitís el certificado nuevo, lo desplegás con la cadena completa, repetís el chequeo de openssl de antes y recién ahí borrás el certificado viejo. Si hacés esto al revés, te quedás sin certificado válido en el medio.

eMudhra ofrece migrar a sus clientes a intermedias bajo emSign Root CA – G1, su root RSA. No me cierra esa opción. Mozilla no está removiendo G1 por ahora, pero es la misma CA cuyos controles de ceremonia acaban de fallar en varios pasos a la vez. Si los programas de root revisan G1 después de la investigación, vas a tener que migrar de nuevo. Mejor hacerlo una sola vez, con cualquier otra CA que tenga endpoint ACME.

Si gestionás hosting y certificados SSL para varios sitios, revisar esto de una sola vez por cuenta te ahorra el susto de un dominio caído en producción. En donweb.com podés comprar certificados SSL con instalación gratuita para completar la migración sin quedarte a mitad de camino.

Errores comunes al reaccionar a este incidente

• Chequear solo el navegador y no el backend. Tu Chrome está protegido, pero tu pipeline de CI, tus workers y tus scripts probablemente siguen confiando en las claves rotas porque leen un bundle de CA viejo del disco.
• Migrar a emSign Root CA – G1 porque eMudhra lo ofrece gratis. Es la misma CA que falló en la ceremonia. Si después la desconfían también, vas a repetir todo el trabajo.
• Desactivar la verificación de certificados para que el error desaparezca. Con la verificación apagada, cualquiera puede hacerse pasar por vos sin necesitar siquiera la clave 4.
• Olvidarse de los bundles de mTLS. Si tu servidor valida certificados de cliente contra un bundle que incluye los roots G3 o las ocho intermedias, un atacante con la clave 4 puede generar un certificado de cliente válido para vos.
• Chequear el repo en vez del edge. El certificado que está en tu repositorio de código no siempre es el que tu CDN o balanceador termina sirviendo al usuario final.

Preguntas Frecuentes

¿Qué certificados de eMudhra fueron comprometidos?

Ocho CA intermedias de eMudhra: seis que emiten certificados TLS (DV, OV y EV, generaciones G3B y G3C) y dos de firma de código. Todas se crearon en abril de 2025 y tenían claves privadas con valores entre 4 y 237, cuando deberían ser números aleatorios de 384 bits.

¿Cómo verifico si mi sitio usa un certificado eMudhra?

Corré openssl s_client -connect tudominio.com:443 -servername tudominio.com -showcerts y filtrá la salida buscando “emsign” o “emudhra” en las líneas de subject e issuer. Si aparece algo, tu cadena de certificados encadena a eMudhra.

¿Por qué Firefox y Chrome eliminaron el root de eMudhra?

Porque bloquear solo las ocho intermedias comprometidas no alcanza: Mozilla le pidió a eMudhra que dejara de emitir desde cualquier intermedia que encadene al root emSign ECC Root CA – G3, y terminó removiendo ese root directamente de NSS 3.131.1 el 20 de octubre de 2026. Chrome confirmó que hará lo mismo en Chrome Root Store v43.

¿Mi servidor Python o Node.js sigue confiando en las claves rotas?

Probablemente sí, salvo que ya hayas actualizado a certifi 2026.10.19 o a Node.js 22.23.4, 24.22.1 o 26.12.1. Estos clientes leen un bundle de CA del disco y no verifican revocación ni Certificate Transparency por defecto, así que una versión vieja sigue aceptando certificados falsificados con estas claves.

¿Cómo migro mi certificado SSL fuera de eMudhra?

Si tu certificado llegó vía ACME, cambiá la URL del directorio ACME a otra CA, agregá el registro CAA correspondiente antes de emitir, desplegá el certificado nuevo con la cadena completa y recién después borrá el viejo.

Conclusión

Lo que cambió esta semana no es solo que eMudhra tuvo un error de seguridad. Cambió la fecha límite para miles de sitios que ni sabían que su cadena de certificados pasaba por una CA india con problemas en su ceremonia de llaves. Si corriste el comando de openssl y te dio resultado limpio, podés respirar. Si no, tenés una ventana corta antes de que tu certificado empiece a fallar para los usuarios que ya actualizaron su navegador o su sistema operativo.

Lo que no sabemos todavía es si alguien explotó estas claves durante los 17 meses que estuvieron expuestas fuera del radar de Certificate Transparency. Puede que nunca lo sepamos. Mientras tanto, lo accionable es concreto: correr el chequeo, actualizar los runtimes de tu stack backend y migrar antes de que el root desaparezca de tu navegador favorito.

Fuentes

• Mozilla Security Blog – Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Alan West en dev.to – eMudhra Certificate Distrust: One CA Key Was 4
• Scott Helme – Eight Bits of Trust
• eMudhra Intermediate CA Compromise – incident page
• Mozilla Bugzilla 2083449 – eMudhra: Private key compromise of Intermediate Certificates