Claves de CA de eMudhra comprometidas, lo que obliga a aplicar correcciones urgentes en navegadores y entornos de ejecución
Mozilla y Google confirmaron el 20 de octubre la vulneración de ocho claves privadas de autoridades intermedias de certificación (CA) de eMudhra, lo que forzó revocaciones de emergencia en los principales navegadores y entornos de ejecución de software.
Traducido automáticamente del original en inglés.
El Programa Raíz de Chrome de Mozilla y Google confirmó el 20 de octubre que las claves privadas de ocho certificados de autoridad intermedia de certificación (CA) de eMudhra han sido comprometidas. Este incidente crítico de seguridad provocó correcciones de emergencia inmediatas en los principales navegadores web y entornos de ejecución de software para prevenir posibles ataques de intermediario (man-in-the-middle). La vulneración fue reportada por un investigador el 17 de octubre, lo que llevó a acciones rápidas de bloqueo por parte de Chrome y Firefox dentro de las horas siguientes a la verificación.
Qué ocurrió
El núcleo de este incidente implica el robo o acceso no autorizado a claves privadas pertenecientes a eMudhra, una autoridad de certificación india que emite certificados digitales bajo la marca emSign. Estas claves específicas pertenecen a certificados intermedios, utilizados para firmar certificados de entidad final para sitios web y software. La posesión de estas claves privadas permite a un atacante emitir certificados TLS válidos para cualquier dominio, los cuales los navegadores confiarían normalmente como legítimos. La vulneración afecta a seis intermediarios usados para cifrado TLS y dos usados para firma de código, abarcando tipos de certificados validados por dominio, validados por organización y con validación extendida.
Un investigador de seguridad, identificado únicamente como Wayne, reportó el problema a los operadores del programa raíz la noche del 17 de octubre. Wayne demostró la posesión de las claves firmando un mensaje con cada una de las ocho claves privadas comprometidas. Chrome verificó los hallazgos e implementó un bloqueo mediante su mecanismo CRLSet antes de las 19:45 UTC del 17 de octubre. Mozilla siguió el ejemplo, enviando un bloque OneCRL a las instalaciones de Firefox antes de las 22:59 UTC del mismo día. Estos mecanismos permiten a los navegadores revocar la confianza en certificados específicos sin requerir una actualización completa del software ni un reinicio. Apple bloqueó los certificados el 19 de octubre, y Microsoft hizo lo propio el 20 de octubre.
Crucialmente, ningún certificado TLS encadenado a los seis intermediarios web afectados había sido registrado en los logs de Certificate Transparency antes de que Chrome implementara su bloqueo. Esto sugiere que, aunque las claves fueron comprometidas, es posible que no se hayan utilizado para emitir certificados fraudulentos que fueran públicamente visibles y confiados por defecto en Chrome. Sin embargo, se desconoce cómo fueron exfiltradas las claves, cuándo ocurrió la brecha o si otros actores además del investigador que reportó el incidente las poseen. Go, el lenguaje de programación, también lanzó actualizaciones de seguridad urgentes el 20 de octubre para rechazar cadenas que contengan estas claves, tratando el problema con máxima severidad debido a la potencial amenaza para la integridad del ecosistema.
Detalles clave
- Ocho claves privadas de CA intermedia de eMudhra fueron comprometidas, afectando tanto a certificados TLS como de firma de código.
- Chrome y Firefox bloquearon los certificados dentro de las horas posteriores al reporte del 17 de octubre, utilizando CRLSet y OneCRL respectivamente.
- No se encontraron certificados TLS fraudulentos encadenados a los intermediarios afectados en los logs de Certificate Transparency antes del bloqueo.
- Go lanzó las versiones 1.27.3 y 1.26.10 el 20 de octubre para rechazar firmemente estas claves, requiriendo que los desarrolladores reconstruyan sus aplicaciones.
- Mozilla eliminó la emSign ECC Root CA - G3 de su almacén de confianza NSS, lo que puede causar problemas de conectividad para servidores que aún utilicen esta raíz.
- El bundle certifi de Python y webpki-roots de Rust se han actualizado para eliminar la raíz afectada, requiriendo actualizaciones de paquetes para servicios backend.
Contexto
Para entender la gravedad, es necesario distinguir entre certificados raíz e intermedios. Un certificado raíz es el ancla última de confianza en un navegador o sistema operativo. Los certificados intermedios actúan como puentes, firmados por la raíz, que luego firman los certificados reales utilizados por los sitios web. Esta jerarquía permite a las CAs mantener sus claves raíz altamente sensibles fuera de línea y seguras. Cuando una clave intermedia se compromete, como en este caso, el daño se contiene más fácilmente que en una vulneración de la raíz, pero aún permite a los atacantes suplantar cualquier sitio web confiado por ese intermediario.
Certificate Transparency (CT) es un sistema de registro público que documenta todos los certificados TLS emitidos. Sirve como pista de auditoría, permitiendo a los propietarios de dominios y navegadores detectar certificados mal emitidos. El hecho de que no existieran logs CT para los intermediarios comprometidos de eMudhra antes del bloqueo es un signo positivo, indicando que el uso indebido a gran escala pudo haberse prevenido o pasó desapercibido para la monitorización pública. Sin embargo, muchos sistemas backend y clientes antiguos no aplican estrictamente el registro CT ni verifican listas de revocación como CRLSet, haciéndolos vulnerables hasta que sus almacenes de confianza sean explícitamente actualizados.
Por qué importa
Para equipos que ejecutan software autoalojado, este incidente destaca la fragilidad de la confianza implícita en autoridades de certificación de terceros. Mientras que los navegadores web reciben actualizaciones automáticas de revocación, muchas aplicaciones del lado del servidor, herramientas internas y microservicios dependen de bundles de confianza estáticos o almacenes de certificados a nivel de sistema que no se actualizan automáticamente. Por ejemplo, las aplicaciones Python que usan el bundle certifi o los binarios Go compilados con versiones antiguas continuarán confiando en las claves comprometidas hasta que las bibliotecas subyacentes sean actualizadas y la aplicación sea redeployada. Esto crea una ventana de vulnerabilidad para APIs internas y comunicación servicio-a-servicio que depende de autenticación mutua TLS.
Además, la eliminación de la emSign ECC Root CA - G3 de almacenes de confianza como NSS de Mozilla y certifi de Python significa que cualquier servicio legítimo que aún utilice certificados encadenados a esta raíz se volverá repentinamente inalcanzable. Esto no es solo una corrección de seguridad, sino un potencial incidente de disponibilidad. Los ingenieros DevOps deben verificar si alguna de sus dependencias externas o integraciones con socios utiliza certificados de eMudhra. Si es así, esas conexiones fallarán hasta que la parte remota reemita sus certificados bajo una raíz diferente y confiable. Esto subraya la necesidad de una monitorización activa de la validez del certificado y cambios en el emisor, en lugar de asumir una confiabilidad de "configurar y olvidar".
Qué puedes hacer
- Actualiza todas las instalaciones de Go a la versión 1.27.3 o 1.26.10 inmediatamente y reconstruye cualquier binario afectado para asegurar que la nueva lógica de rechazo esté activa.
- Revisa tus entornos de Python y actualiza el paquete certifi a la versión 2026.10.19 o posterior para eliminar la raíz no confiable de tu bundle.
- Audita los logs de tu servidor para cualquier conexión a servicios que usen certificados de eMudhra, ya que estos pueden ahora fallar debido a la eliminación de la raíz en los almacenes de confianza actualizados.
- Verifica que tus sistemas de monitorización internos estén comprobando cambios en el emisor del certificado, no solo fechas de expiración, para detectar migraciones o vulneraciones similares tempranamente.
- Asegúrate de que tus instalaciones de Firefox estén actualizadas a la versión 158.0.1, ESR 115.43.1 o ESR 153.5.1 si no pueden recibir actualizaciones de Remote Settings automáticamente.
- Revisa tu gestión de dependencias para proyectos en Rust y Node.js, vigilando actualizaciones pendientes de webpki-roots y del propio Node.js que aborden esta vulneración.



