Chrome programa retirar hoy la raíz emSign vinculada al incidente de eMudhra

Google anunció que el 27 de octubre de 2026, hora del Pacífico, espera desplegar en todos los dispositivos que usan Chrome Root Store la eliminación de confianza para emSign ECC Root CA – G3. La medida sigue al hallazgo de ocho certificados intermedios de eMudhra con claves privadas criptográficamente débiles. Google y Mozilla ya habían bloqueado las claves intermedias; la retirada de la raíz amplía la respuesta de Chrome a clientes que no procesan correctamente información de revocación.

La fecha es un calendario comunicado por Google, no una confirmación pública de que cada navegador haya recibido ya la actualización. Google indicó que la distribución empezaría antes en los canales Canary y Beta. Sitios y servicios que dependan de certificados legítimos encadenados a esa raíz podrían dejar de validarse en Chrome después del cambio, aunque no estén involucrados en un ataque.

eMudhra informó que el 17 de octubre un investigador externo comunicó que las claves de ocho autoridades certificadoras intermedias de su negocio internacional TLS eran débiles. La compañía relacionó el problema con una ceremonia de generación de claves en abril de 2025 y anunció la desconfianza de esas autoridades. Google dijo haber recibido el reporte ese 17 de octubre y desplegó bloqueo de las claves; Firefox distribuyó también medidas para impedir que se acepten los certificados comprometidos.

Una autoridad intermedia puede emitir certificados de sitios web bajo una raíz confiable. Si un atacante conoce su clave privada, en principio puede intentar emitir certificados falsos que los clientes interpreten como válidos. El problema descrito afecta a la infraestructura pública TLS de eMudhra, no a todos los certificados TLS ni a todas las operaciones de la empresa. eMudhra afirmó que sus servicios indios de firma digital y eSign no estaban conectados con este incidente.

El impacto de continuidad se concentra en operadores cuyos certificados activos o cadenas de certificados dependen de emSign ECC Root CA – G3. A medida que navegadores distribuyan la desconfianza, los visitantes podrían recibir advertencias o fallos de conexión si el sitio no migra a una cadena reconocida. La afectación no se infiere solo del nombre comercial del emisor: es necesario revisar el certificado presentado, la cadena completa y la raíz final.

Google comunicó que no encontró certificados de sitios web emitidos por seis de las intermedias afectadas en los registros públicos de Certificate Transparency que revisó, lo que reduce un tipo de riesgo para clientes de navegador que aplican esa protección. No elimina todas las posibilidades de abuso en software, equipos antiguos o clientes que no consultan dichos registros. Tampoco demuestra por sí solo que ningún certificado haya sido utilizado en otro contexto.

La documentación de Google fija la fecha prevista para Chrome y explica que algunos certificados legítimos podrían dejar de funcionar. La declaración de eMudhra describe el incidente y la separación de sus líneas de negocio; Cloudflare y BleepingComputer aportan análisis independiente de la respuesta del ecosistema. Estos avisos corroboran un evento de confianza de certificados, no un reporte de que una entidad determinada haya sido suplantada o que datos hayan sido interceptados.

Para organizaciones ecuatorianas, la raíz de confianza no crea una nueva obligación legal local. Sí es una cuestión práctica de disponibilidad y seguridad cuando servicios propios, proveedores o dependencias de software usan certificados afectados. Sitios web, portales de clientes, aplicaciones móviles, APIs, proxies TLS, appliances y runtimes pueden mantener almacenes de confianza distintos; una actualización del navegador de escritorio no garantiza que todos ellos hayan recibido el cambio.

Los responsables de sitios deben inspeccionar los certificados activos y la ruta de certificación de todos los dominios, subdominios y endpoints de API. Si la cadena termina en la raíz señalada, coordinen cuanto antes la emisión y despliegue de un certificado bajo una autoridad aún confiable, y prueben el cambio en Chrome estable, en canales preliminares y en clientes no navegador que consumen la misma API. Soliciten a su proveedor de alojamiento o TLS una confirmación explícita si la gestión del certificado está tercerizada.

Mantenga navegadores, sistemas y almacenes de certificados actualizados; revise también contenedores, dispositivos integrados y software que incluya sus propias raíces. No desactive la validación TLS para sortear una alerta ni instruya a usuarios a ignorar errores. Si aparecen fallos, registre la cadena presentada, la hora, el cliente y el endpoint antes de renovar, para separar problemas de confianza de errores de configuración. La ventana del 27 de octubre exige priorizar inventario y continuidad, pero la evidencia disponible no permite afirmar que la eliminación ya haya llegado a todos los dispositivos.