Ocho certificados intermedios de eMudhra emSign comprometidos; navegadores los bloquean

El 20 de octubre los principales programas de raíces de navegadores confirmaron que las claves privadas asociadas a ocho certificados intermedios emitidos por eMudhra (marca comercial emSign) quedaron comprometidas. Un certificado intermedio puede emitir, por delegación de la raíz, certificados válidos para cualquier dominio; quien posea su clave privada podría crear certificados que los navegadores aceptarían como legítimos. Las firmas públicas y la cronología del aviso permiten reconstruir qué ocurrió y qué impactos concretos cabe esperar, pero quedan preguntas sin respuesta sobre el origen y la extensión de la fuga.

Hechos confirmados: un investigador notificó la detección la tarde del 17 de octubre (UTC), y Chrome implementó un bloqueo técnico de las claves ese mismo día entre las 18:05 y las 19:45 UTC; Firefox recibió la notificación a las 20:06 UTC y distribuyó su bloqueo (OneCRL) a instalaciones estándar a las 22:59 UTC. Los ocho intermedios afectados son: EM DV TLS CA - G3B; EM DV TLS CA - G3C; EM OV TLS CA - G3B; EM OV TLS CA - G3C; EM EV TLS CA - G3B; EM EV TLS CA - G3C; EM OV CS CA - G3B; y EM OV CS CA - G3C. Se confirmó además que cada certificado tiene una copia cross‑firmada por Sectigo bajo su raíz AAA Certificate Services, y que eMudhra ha revocado los ocho certificados tras la notificación. Un ingeniero de Mozilla, Dennis Jackson, publicó la lista de certificados y los sellos que demostraban la firma con las claves comprometidas.

Técnicamente, el riesgo concreto dependía de si ya existían certificados emitidos por estos intermedios y si esos certificados habían sido registrados en Certificate Transparency (CT). Chrome comprobó que no había entradas CT conectadas a los seis intermedios usados para TLS antes del bloqueo, por lo que, según su verificación, ningún navegador que exige CT habría estado confiando por defecto en certificados nuevos firmados por esas claves. Aun así, la existencia de copias cross‑firmadas y la presencia de las raíces en distintos almacenes complican el panorama.

Qué programas y usuarios quedaron afectados: navegadores que implementan mecanismos de revocación centralizada (Chrome con CRLSet, Firefox con OneCRL y Apple en sus listas) recibieron el bloqueo rápidamente y dejaron de confiar en los intermedios; Microsoft y otros proveedores también bloquearon los certificados. Sin embargo, muchas aplicaciones y bibliotecas que validan TLS fuera de esos navegadores no consultan ni aplican revocación de forma efectiva. Ejemplos relevantes: binarios de Go, entornos que usan la colección certifi de Python, y montones de distribuciones de Linux que confían en almacenes locales de certificados pueden seguir validando cadenas mientras el software no se actualice o el bundle no cambie.

Acciones técnicas ya tomadas y sus efectos: Google implementó un filtro en la librería estándar de Go que detecta y rechaza cualquier cadena que contenga las claves comprometidas; esa corrección requiere recompilar los programas con la versión de Go parcheada. Otros proyectos (certifi, webpki-roots, Homebrew) optaron por eliminar la raíz emSign ECC Root CA - G3 de sus paquetes, una medida efectiva para cortar confianza, pero que también rompe la validación para cualquier servidor legítimo que aún dependa de esa raíz. Mozilla y NSS aplicaron la misma exclusión, y advirtieron que algunos servidores dejarán de ser accesibles para clientes que usan esos repertorios hasta que esos servidores migren a certificados encadenados a otras raíces.

Información todavía incierta: no se ha publicado cómo ni cuándo exactamente salieron las claves de eMudhra, ni si la divulgación fue externa o interna; tampoco existe evidencia pública de abuso previo salvo la firma que el investigador usó para probar la posesión (el mensaje firmado con cada clave). Mozilla indica que está trabajando con la CA en una investigación forense, pero los detalles del vector de fuga no han sido divulgados.

Consecuencias prácticas: a corto plazo, los navegadores modernos que reciben bloqueo centralizado protegen a la mayoría de usuarios frente a certificados falsos emitidos con esas claves. Aun así, sistemas que no aplican revocación o que no usan los almacenes actualizados seguirán expuestos, y la estrategia de retirar la raíz de bundles populares puede producir indisponibilidad temporal de servicios legítimos hasta que sus operadores sustituyan los certificados. A medio plazo, la confianza en eMudhra/emSign quedará afectada y los programas que dependan de sus raíces deberán evaluar la necesidad de rotación de certificados y auditorías adicionales.

Recomendaciones concretas —confirmadas y accionables— según el tipo de lector: para administradores de servidores TLS, primero compruebe si su certificado actual encadena a emSign Root TLS CA - G3 o emSign ECC Root CA - G3; si es así, obtenga y despliegue un certificado nuevo que encadene a una raíz distinta y válida lo antes posible, y confirme que sus nuevos certificados están registrados en Certificate Transparency. Herramientas y búsquedas CT públicas ayudan a detectar emisiones inesperadas: consulte la base de datos de Certificate Transparency en https://www.certificate-transparency.org/ y las vistas de Google en https://transparencyreport.google.com/https/certificates/overview.

Para operadores de software y desarrolladores: actualice bibliotecas y binarios afectados. Si usa Go, reconstruya sus proyectos con la versión de Go que contiene el bloqueo de claves; Go publica información de seguridad y versiones en https://go.dev/security. Si su software incorpora bundles externos (certifi, webpki-roots, Homebrew ca-certificates, NSS), actualícelos y pruebe el impacto en entornos de staging antes de desplegar en producción, porque algunos bundles han optado por retirar la raíz completa y eso puede romper conexiones.

Para administradores de seguridad y responsables de confianza: verifique que sus clientes y agentes confíen en revocación y en Remote Settings/actualizaciones automáticas de las listas de bloqueo; si su entorno impide que Firefox o Chrome reciban OneCRL/CRLSet, implemente controles adicionales (lista de bloqueo de intermediarios por clave pública en los proxies, inspección TLS) o considere eliminar temporalmente la confianza en las raíces emSign hasta que haya certeza de que no existen emisiones fraudulentas.

Para usuarios finales: mantenga navegadores y sistemas actualizados. Los navegadores citados han recibido y aplicado bloqueos que protegen a la mayoría de usuarios sin intervención manual; si un sitio deja de cargar tras las actualizaciones, es probable que su operador de servidor deba renovar el certificado.

Qué monitorizar ahora: búsquedas continuas en CT para detectar certificados emitidos por las claves comprometidas, registro y auditoría del uso de interfaces de emisión por parte de la CA, y comunicados oficiales de eMudhra y de los programas de raíces. Las causas raíz siguen siendo un asunto pendiente y justifica que las organizaciones revisen sus dependencias de confianza de terceros y políticas de revocación para reducir el impacto de fallas similares en el futuro.

Resumen: las claves de ocho intermedios de eMudhra fueron comprometidas y bloqueadas rápidamente por los grandes programas de raíces; navegadores modernos ya aplican mitigaciones, pero muchas aplicaciones fuera de esos clientes siguen vulnerables hasta que se actualicen o se reconstruyan. Es imprescindible que administradores renueven certificados encadenados a las raíces afectadas, que desarrolladores recompilen con versiones de librerías parcheadas y que equipos de seguridad auditen la aceptación de revocación dentro de su entorno.