The eMudhra SSL certificate trust removal requires operators to replace any certificate chain ending at emSign ECC Root CA – G3. Google scheduled Chrome’s removal for the morning of October 27, 2026, Pacific time, while Apple began blocking the root on October 23, 2026. Check every public TLS endpoint, install a chain under a trusted root, and test it externally.
¿Por qué Chrome está retirando la confianza en la raíz de eMudhra?
Chrome está retirando la confianza en emSign ECC Root CA – G3 porque la raíz firmó una jerarquía que contenía claves comprometidas de autoridades de certificación intermedias de eMudhra. Google programó la retirada de la raíz de Chrome Root Store para el 27 de octubre de 2026, después de bloquear las claves intermedias afectadas mediante CRLSet el 17 de octubre de 2026.
La retirada de confianza de los certificados SSL de eMudhra se produjo tras un informe según el cual las claves privadas de ocho certificados de CA intermedias podían recuperarse porque tenían una aleatoriedad insuficiente. Según el aviso de seguridad de Google de octubre de 2026, seis intermedias se utilizaban para TLS y dos para la firma de código.
Una autoridad de certificación intermedia es una CA que firma certificados subordinados a una raíz de confianza, creando una ruta verificable entre el certificado de un sitio web y la raíz almacenada por un navegador o sistema operativo. La posesión de una de las seis claves intermedias TLS podría haber permitido a un atacante crear certificados aparentemente válidos para sitios web arbitrarios en clientes que no hubieran bloqueado la clave.
Google declaró en octubre de 2026 que no se habían emitido certificados TLS de entidades finales de confianza pública a partir de esas seis intermedias comprometidas antes del bloqueo. El peligro residía en la capacidad de firma expuesta, no en pruebas de una falsificación generalizada de certificados de sitios web.
eMudhra revocó las ocho intermedias en aproximadamente 14 horas, entre el 17 y el 18 de octubre de 2026. Las claves débiles pertenecían a CA intermedias, no a la propia raíz, pero Google retiró emSign ECC Root CA – G3 como medida de precaución porque actuaba como ancla de la jerarquía comprometida.
¿Se han falsificado los 30.800 certificados afectados?
No. Los aproximadamente 30.800 certificados o precertificados no caducados identificados mediante Certificate Transparency el 21 de octubre de 2026 eran certificados legítimos encadenados a emSign ECC Root CA – G3. El análisis del incidente de Mozilla no clasificó esos certificados como falsificaciones; la retirada de confianza de la raíz convirtió su ruta de confianza en el problema operativo.
La distinción es importante. Una clave de firma comprometida crea la capacidad de falsificar certificados, mientras que un certificado legítimo puede dejar de ser utilizable simplemente porque los navegadores dejan de confiar en una raíz situada en otra parte de su cadena. Tratar todos los certificados afectados como maliciosos exagera el incidente y puede distraer de las tareas de sustitución.
| Ruta o grupo de certificados | Cantidad comunicada | Qué significa la cantidad |
|---|---|---|
| InCommon Intermediate CA – OVG3C | 23,806 | Certificados legítimos asociados a una CA subordinada de Internet2/InCommon |
| InCommon Intermediate CA – DVG3C | 6,985 | Certificados legítimos asociados a una CA subordinada de Internet2/InCommon |
| Dos intermedias de InCommon combinadas | 30,791 | Certificados que requieren migración desde la ruta de la raíz afectada |
| Intermedias operadas por eMudhra | 18 | Certificados adicionales comunicados en la revisión de Certificate Transparency |
| Población afectada redondeada | Aproximadamente 30.800 | Certificados o precertificados no caducados encadenados a la raíz cuya confianza se ha retirado |
Los dos subtotales mostrados, 30.791 y 18, suman 30.809. Esto supera la cifra principal redondeada de «aproximadamente 30.800», por lo que no debe convertir los valores publicados en un total falsamente exacto. El análisis de Mozilla de octubre de 2026 también comunicó la estimación de eMudhra de que aproximadamente 97% de unos 30.000 certificados se habían emitido mediante ACME.
Esta concentración explica por qué las redes universitarias y de investigación que utilizan Internet2/InCommon merecen una atención especial. Una gran cantidad de certificados bajo dos CA subordinadas no significa que se produjeran miles de compromisos independientes. Significa que una sola decisión de confianza puede tener amplios efectos posteriores.
¿Cómo se comprueba si una cadena de certificados de eMudhra está afectada?
Compruebe una cadena de certificados de eMudhra inspeccionando lo que envía el servidor activo, buscando «emSign» o «eMudhra» en la ruta del emisor e identificando el ancla de confianza terminal. Una cadena que termine en emSign ECC Root CA – G3 está afectada por la retirada de confianza de octubre de 2026, aunque el certificado final no haya caducado.
Las directrices de SSL.com de octubre de 2026 recomiendan consultar el punto final con openssl s_client -connect hostname:443 -servername hostname -showcertsSustituya ambas apariciones de hostname por el nombre DNS real. La indicación del nombre del servidor es importante porque una dirección IP compartida puede devolver un certificado predeterminado cuando se omite -servername .
Lea los certificados devueltos en orden y examine cada sujeto y emisor. No se limite a comprobar el certificado final. La retirada de confianza de los certificados SSL de eMudhra afecta a la ruta de certificación, por lo que un certificado de dominio de aspecto normal puede seguir fallando cuando el servidor proporciona una intermedia afectada o el cliente construye la ruta hacia la raíz retirada.
One commonly missed pitfall is testing only the main website. Inventory API hostnames, authentication portals, CDN origins, mail services, load balancers, gateways, staging systems, container ingress points and vendor-managed endpoints. Operators responding to other urgent issues, such as an vulnerabilidad de GitLab explotable activamente, ya saben que los servicios secundarios olvidados suelen prolongar la limpieza del incidente.
¿Cómo se sustituye un certificado afectado antes de la retirada de confianza?
Sustituya un certificado afectado obteniendo un nuevo certificado final que se encadene a una jerarquía actualmente de confianza, instalando la cadena intermedia completa prevista y desplegándola en todos los puntos de terminación TLS. eMudhra comenzó a ofrecer sustituciones emitidas por Sectigo a través de CertiNext o del soporte de eMudhra el 22 de octubre de 2026.
La siguiente secuencia de corrección de octubre de 2026 cubre los puntos de fallo que con mayor probabilidad pueden dejar un nombre de host inoperativo:
- Haga inventario de todos los sitios web, API, CDN, equilibradores de carga, servidores de correo, pasarelas, puntos de entrada de contenedores y demás puntos finales TLS públicos.
- Inspeccione cada ruta activa y marque las cadenas que contengan eMudhra, emSign o emSign ECC Root CA – G3.
- Solicite un certificado de sustitución a una CA cuya cadena siga siendo de confianza para los navegadores, sistemas operativos y entornos de ejecución de aplicaciones necesarios.
- Instale el nuevo certificado final y el paquete completo de certificados intermedios en cada capa de terminación, incluidos los extremos gestionados por proveedores.
- Fuerce o reconfigure la emisión mediante ACME cuando la fecha normal de renovación sea posterior a la fecha límite de retirada de confianza de octubre de 2026.
- Vuelva a probar cada nombre de host desde fuera de su red y confirme la cadena que reciben los clientes actuales.
La automatización de ACME no demuestra que exista seguridad. El análisis del incidente de octubre de 2026 de Mozilla advirtió explícitamente a los operadores que no dieran por hecho que un calendario de renovación normal sustituiría la ruta afectada a tiempo. Fuerce la renovación cuando sea necesario y, después, inspeccione la cadena resultante en lugar de confiar en un registro de tarea completada correctamente.
Un cálculo concreto muestra el riesgo: un certificado de 90 días al que le quedan 45 días, con un cliente ACME configurado para renovarse cuando queden 30 días, no intentará realizar la renovación rutinaria hasta dentro de otros 15 días. Si la desconfianza en la raíz se produce hoy, la automatización funciona exactamente según su configuración, mientras que el sitio sigue fallando hoy.
Sinceramente, sustituir únicamente el servidor web público es un atajo poco recomendable. El despliegue de certificados se parece a otras tareas de respuesta ante emergencias: la disciplina de inventario utilizada para los incidentes de servidores de copia de seguridad sin parches también se aplica a los endpoints TLS ocultos tras proxies y puertas de enlace.
¿Cómo puede verificar que la sustitución funciona realmente?
Verifique la sustitución de eMudhra probando cada nombre de host público desde una red externa, confirmando que el servidor envía los certificados intermedios previstos y conectándose con Chrome actualizado y otros clientes principales. Las directrices de Google de octubre de 2026 también exigen actualizar los entornos de ejecución, las imágenes base y las aplicaciones que mantienen almacenes de confianza de certificados independientes.
Empiece con otra consulta de openssl s_client contra el endpoint activo, no contra un archivo de certificado local. Confirme que la ruta antigua de eMudhra está ausente y que el servidor proporciona los certificados intermedios necesarios. Después, utilice versiones actuales de los navegadores y sistemas operativos representativos desde fuera de la red corporativa.
Apple adds an awkward edge case. Apple reported on October 23, 2026, that some macOS command-line tools, including curl, git, Python, Ruby, Perl and OpenSSL, could continue using /etc/ssl/cert.pem hasta una futura actualización de software, de forma independiente del bloqueo de plataforma de Apple. Por tanto, una solicitud curl correcta puede no demostrar que Safari u otro cliente que confíe en la plataforma acepte la misma cadena.
Apple empezó a bloquear el 19 de octubre de 2026 12 certificados que representaban las seis claves intermedias TLS de las rutas de eMudhra y Sectigo, y después bloqueó emSign ECC Root CA – G3 el 23 de octubre de 2026. Son posibles resultados dispares entre aplicaciones, porque los navegadores, los sistemas operativos y los entornos de ejecución incluidos pueden consultar almacenes de confianza distintos.
Registre el nombre de host, la cadena observada, la versión del cliente, el sistema operativo y la hora de la prueba para cada resultado. Estas pruebas son mucho más útiles que una captura de pantalla que diga «a mí me funciona», especialmente cuando un equipo de seguridad también está siguiendo riesgos de confianza específicos de los navegadores, como los fallos de confianza de las extensiones de Chrome.
¿Qué significa la salida de eMudhra del mercado SSL/TLS global?
El consejo de administración de eMudhra decidió el 22 de octubre de 2026 abandonar el negocio global de certificados SSL/TLS. eMudhra afirmó que sus raíces G1 RSA seguirían operativas durante la migración, mientras que los servicios de revocación y de estado de los certificados permanecerían disponibles hasta que los certificados emitidos caducasen o los clientes los sustituyeran.
La empresa informó de que el negocio global de SSL/TLS representaba aproximadamente el 1% de sus ingresos globales en 2026. El 26 de octubre de 2026, eMudhra reconoció que un error en su propio script había causado el incidente de claves débiles, se disculpó y afirmó que se llevarían a cabo una revisión por expertos independientes y un informe completo de análisis de la causa raíz en la Common CA Database.
Según la explicación de eMudhra, las ocho CA intermedias se originaron durante una ceremonia de generación de claves celebrada el 30 de abril de 2025. Un error en un script de envoltura/desenvoltura creó un segundo conjunto de claves débiles, que se utilizó por error para las solicitudes de firma de certificados.
La retirada de la confianza en los certificados SSL de eMudhra no significa automáticamente que todos los certificados G1 RSA fallen el 27 de octubre de 2026. La confianza depende de la ruta exacta que construya el cliente. Aun así, la salida de eMudhra del negocio hace que una migración planificada sea más sensata que esperar hasta el último día de validez de cada certificado.
Preguntas frecuentes sobre el incidente de certificados de eMudhra
¿Se ha comprometido la clave privada raíz de eMudhra?
En octubre de 2026 no se informó de que la clave privada de emSign ECC Root CA – G3 estuviera comprometida. Las claves recuperables pertenecían a ocho CA intermedias, mientras que la raíz se eliminó porque anclaba la jerarquía afectada.
¿Un certificado de eMudhra que no haya caducado seguirá mostrando una advertencia?
Un certificado que no ha caducado puede mostrar una advertencia cuando su cadena termina en emSign ECC Root CA – G3 después de que un cliente retire la confianza. Las fechas de validez del certificado no anulan la decisión del almacén de raíces del navegador.
¿Revocar los certificados intermedios soluciona los sitios web existentes?
La revocación de los ocho certificados intermedios el 18 de octubre de 2026 redujo el riesgo de abuso, pero no migró los sitios legítimos fuera de la raíz no confiable. Los operadores afectados todavía necesitan una cadena de reemplazo bajo una jerarquía de confianza.
¿Puede una prueba de OpenSSL satisfactoria demostrar que Chrome funcionará?
Que OpenSSL indique que todo es correcto no garantiza que Chrome lo acepte, porque OpenSSL y Chrome pueden utilizar distintos almacenes de confianza y reglas de construcción de rutas. Prueba el nombre de host activo con la versión actual de Chrome después de confirmar la cadena de certificados en la línea de comandos.