El 17 de octubre de 2026 se reportó que las claves privadas de ocho CA intermedias de eMudhra están comprometidas. Con esas claves, un atacante podría emitir certificados válidos para sitios que no controla. Chrome y Firefox las bloquearon el mismo día, Apple el 19 y Microsoft el 20. Si tu empresa tiene certificados emitidos por eMudhra, hay que inventariarlos y planificar su reemplazo.
Un investigador de seguridad que firma como Wayne demostró que tenía las claves privadas de ocho certificados intermedios de eMudhra. La prueba fue directa: firmó el mensaje "We have a problem here - Wayne" con cada una de las ocho claves y entregó los certificados, las claves públicas y las firmas a los programas de raíces de los navegadores, junto con los comandos para verificarlo.
El reporte llegó a Chrome a las 18:05 UTC y a Mozilla a las 20:06 UTC del 17 de octubre. Dennis Jackson, de Mozilla, lo publicó ese mismo día en la lista dev-security-policy.
Una CA intermedia es el eslabón que une la raíz de confianza que viene dentro de tu navegador con el certificado de un sitio concreto. Quien tiene su clave privada puede firmar certificados nuevos, y esos certificados se ven legítimos ante cualquier equipo que confíe en esa cadena. Por eso un compromiso a este nivel es grave: no afecta a un sitio, afecta a todo lo que la intermedia podía firmar.
De las ocho intermedias, seis emiten certificados TLS y dos son de firma de código. Chrome no necesitó bloquear estas últimas para TLS, porque su lógica de validación no construye cadenas de servidor a través de intermedias restringidas al uso de firma de código. Es, en la práctica, una demostración de para qué sirve la separación de usos extendidos de clave que el CA/Browser Forum viene empujando desde 2025.
La respuesta fue rápida y coordinada. Todas las horas son UTC.
| Fecha | Quién | Qué hizo |
|---|---|---|
| 17 de octubre, 19:45 | Chrome | Actualización de CRLSet bloqueando las seis intermedias que emiten TLS |
| 17 de octubre, 22:59 | Firefox | Bloqueo vía OneCRL, sin necesidad de actualizar ni reiniciar el navegador |
| 19 de octubre | Apple | Bloqueo en sus dispositivos y aviso a los almacenes de confianza derivados |
| 20 de octubre | Microsoft | Bloqueo de los certificados afectados |
| 20 de octubre | Mozilla | Versión de NSS que elimina la raíz que firmó las intermedias |
Chrome bloqueó por huella de la clave pública (SPKI) y no por certificado, de modo que el bloqueo alcanzó también a los certificados cruzados emitidos por Sectigo que compartían esas mismas claves. Además anunció que retirará la raíz de eMudhra en la versión 43 de su almacén de raíces, y que está trabajando con los mantenedores de los registros de Certificate Transparency para que rechacen certificados que encadenen a estas intermedias.
Mozilla aclaró que la eliminación de la raíz en NSS no es necesaria para Firefox, porque OneCRL ya cerró el problema; la actualización apunta a los sistemas que usan NSS por debajo.
Dos puntos que conviene no adelantar, porque a la fecha de esta nota no están resueltos.
Cómo se expusieron las claves. Ni el reporte público ni las comunicaciones de los programas de raíces explican de dónde salieron. No se sabe si hubo una intrusión, un error de configuración, una copia mal resguardada o un fallo en el proceso de generación. eMudhra aún no publica el análisis de causa raíz que corresponde en estos casos.
Si alcanzaron a emitirse certificados falsos. Acá hay una buena noticia. Chrome informó que, antes del bloqueo, no se registró en Certificate Transparency ningún certificado TLS que encadenara a estas intermedias. Como los navegadores que exigen CT no confían en un certificado que no esté registrado, eso significa que no hay certificados fraudulentos conocidos que hayan sido aceptados por defecto. El riesgo era real, pero se cerró antes de que se materializara.
Sobre si otras CA están en la misma situación, Mozilla respondió que por ahora no creen que el problema las afecte, y Chrome dijo haber revisado todas las CA dentro de su ámbito de confianza sin encontrar otro caso del mismo tipo.
Si visitas sitios con certificados de eMudhra desde un navegador actualizado, ya estás protegido: el bloqueo llegó solo, sin que tuvieras que hacer nada.
El problema está del otro lado, en quien emite. Si tu empresa usa certificados de eMudhra, esos certificados dejaron de ser confiables para los navegadores actualizados. Y hay un grupo que suele quedar fuera del radar: los sistemas que no se actualizan solos.
En esos casos el bloqueo no te protege: te rompe el servicio, y a veces sin un mensaje claro de por qué.
Lo que define el impacto de un incidente así no es la gravedad del fallo, sino cuánto demoras en saber si te afecta. Las empresas con un inventario al día respondieron en horas: filtraron por emisor, encontraron los certificados de eMudhra y empezaron el reemplazo. Las que no lo tienen van a pasar semanas averiguando qué tienen instalado y dónde.
Ese es el argumento de fondo para automatizar la gestión del ciclo de vida de los certificados, y no depende de qué CA uses. Con vigencias que bajan a 100 días en 2027 y a 47 en 2029, el inventario manual ya era insostenible por volumen. Un incidente como este agrega la otra razón: cuando una CA cae, necesitas poder responder la pregunta "¿qué tengo emitido por ellos?" en minutos.
Si quieres ver qué herramientas de tu stack se integran con la gestión de certificados, el repositorio de integraciones tiene el catálogo. Y para revisar el estado del certificado de un dominio puntual, está el verificador ↗.
Te ayudamos a inventariar tus certificados, identificar cuáles dependen de la CA afectada y planificar el reemplazo, sea cual sea el emisor.
Solicitar diagnóstico
