Detectado un fallo criptográfico que compromete la confianza en los certificados digitales

Mozilla y Google han confirmado el compromiso de las claves privadas asociadas a ocho certificados de autoridades de certificación intermedias de eMudhra, una entidad emisora de certificados digitales integrada en la infraestructura pública de confianza de Internet.

El incidente fue comunicado el 17 de octubre de 2026 por un investigador de seguridad que demostró que las claves privadas podían recuperarse debido a una generación criptográfica defectuosa. Posteriormente, los equipos de seguridad de Mozilla y Google verificaron los hallazgos y adoptaron medidas para impedir que los certificados afectados siguieran siendo considerados fiables.

La gravedad del incidente reside en que una autoridad de certificación intermedia dispone de capacidad para firmar certificados digitales que pueden ser reconocidos como legítimos por navegadores y otros sistemas. Si un atacante obtiene su clave privada, podría generar certificados fraudulentos para dominios que no controla y utilizarlos para suplantar servicios legítimos frente a clientes que continúen confiando en esa autoridad.

La posibilidad de emitir estos certificados no implica por sí misma que se hayan producido ataques efectivos. Hasta el momento, las fuentes oficiales consultadas no han acreditado una campaña de explotación que haya utilizado las claves comprometidas.

Qué ha ocurrido y cuál es el origen del problema
La investigación publicada en el sistema de seguimiento de incidencias de Mozilla identifica un defecto en el procedimiento de generación de claves realizado por eMudhra el 30 de abril de 2025.

Las ocho claves afectadas utilizaban criptografía de curva elíptica P-384, un algoritmo que, correctamente implementado, ofrece un nivel de seguridad elevado. Sin embargo, el problema no se encontraba en el algoritmo, sino en la selección de los valores utilizados como claves privadas.

En lugar de generarse a partir de números aleatorios suficientemente grandes, las claves privadas afectadas tenían valores inferiores a 256.

Esto redujo drásticamente el espacio de búsqueda necesario para recuperarlas. Los investigadores comprobaron que podían reconstruirse prácticamente de forma inmediata a partir de las correspondientes claves públicas.

Mozilla consiguió recuperar las claves de manera independiente, confirmando que el problema era reproducible y que no dependía de información secreta obtenida mediante una intrusión en los sistemas de eMudhra.

Este hecho resulta especialmente significativo porque demuestra que el uso de algoritmos criptográficos robustos no garantiza la seguridad cuando existen deficiencias en los procedimientos de generación y gestión de claves.

Cómo puede afectar a las conexiones HTTPS
La seguridad de una conexión HTTPS depende de distintos mecanismos, entre ellos la validación del certificado digital presentado por el servidor.

En una infraestructura de clave pública o PKI, los certificados de los sitios web se validan mediante una cadena de confianza que conecta el certificado del servidor con una autoridad de certificación raíz reconocida por el sistema.

Las autoridades de certificación intermedias participan en esa cadena y pueden emitir certificados dentro de los límites de sus autorizaciones.

Cuando la clave privada de una autoridad intermedia queda comprometida, un atacante podría utilizarla para firmar certificados fraudulentos.

Si el sistema cliente todavía confía en esa autoridad y acepta la cadena presentada, el certificado podría utilizarse para suplantar la identidad de un servicio legítimo.

En un escenario en el que el atacante también pudiera interceptar o redirigir las comunicaciones, esto podría facilitar ataques de intermediario o Man-in-the-Middle, con posibles consecuencias para la confidencialidad e integridad del tráfico.

No obstante, la explotación efectiva requiere condiciones adicionales. El compromiso de estas claves no permite interceptar automáticamente todas las conexiones HTTPS ni implica que los mecanismos de cifrado TLS hayan sido vulnerados.

El riesgo depende de la cadena de certificación, de las restricciones aplicables al certificado, de los mecanismos de validación utilizados por el cliente y de las medidas de revocación o desconfianza que se hayan desplegado.

Ocho certificados comprometidos, con distintos usos
La investigación identifica ocho certificados intermedios afectados, de los cuales seis estaban destinados a la emisión de certificados TLS y dos a la firma de código.

Esta distinción es relevante porque no todos los certificados comprometidos tienen las mismas capacidades ni pueden utilizarse indistintamente para suplantar sitios web.

Google ha confirmado que los seis certificados intermedios relacionados con TLS fueron bloqueados mediante sus claves públicas. Los dos certificados destinados a firma de código no requerían el mismo bloqueo en el proceso de validación HTTPS de Chrome debido a las restricciones de uso de sus certificados.

eMudhra ha comunicado que ninguna de las autoridades intermedias afectadas había emitido certificados finales legítimos, aunque una de ellas llegó a desplegarse en producción.

La compañía también indica que el incidente no afecta a las claves privadas de sus autoridades raíz ni, según la investigación realizada hasta el momento, a sus restantes autoridades intermedias.

Por tanto, el incidente debe circunscribirse a los certificados y claves identificados, sin extender automáticamente el compromiso al conjunto de los servicios de certificación de eMudhra.

Mozilla y Google han desplegado medidas de protección
Tras recibir la notificación, Mozilla y Google iniciaron procedimientos de respuesta destinados a retirar la confianza en los certificados afectados.

Mozilla
Mozilla utilizó OneCRL, su sistema centralizado de bloqueo de certificados, para impedir que Firefox aceptara las autoridades intermedias comprometidas.

La distribución de esta protección se completó el 17 de octubre, menos de tres horas después de recibir la notificación, para los usuarios de Firefox con configuraciones estándar.

Adicionalmente, Mozilla publicó Firefox 158.0.1 y las versiones ESR 115.43.1 y 153.5.1, destinadas a extender la protección a configuraciones que pudieran no recibir las actualizaciones de OneCRL.

También anunció la eliminación de la autoridad raíz emSign ECC Root CA - G3 del almacén de confianza de NSS 3.131.1, con el objetivo de proteger aplicaciones que utilizan esta infraestructura de certificados pero no reciben las actualizaciones centralizadas de Firefox.

Google
Google confirmó que las claves privadas afectadas se habían generado con aleatoriedad insuficiente y distribuyó una actualización de CRLSet para bloquear las claves públicas de las seis autoridades intermedias TLS comprometidas.

Este mecanismo permite rechazar los certificados asociados a dichas claves sin necesidad de actualizar o reiniciar Chrome.

Google también distribuyó medidas equivalentes para dispositivos Android mediante Google Play Services.

Asimismo, anunció la retirada de emSign ECC Root CA - G3 del Chrome Root Store, prevista para el 27 de octubre de 2026. Esta medida puede afectar a servicios legítimos que todavía utilicen cadenas de certificación dependientes de dicha autoridad raíz.

Los operadores de estos servicios deberán comprobar sus certificados y, cuando corresponda, sustituirlos por otros emitidos bajo una jerarquía de confianza admitida.

La transparencia de certificados limita determinados escenarios de explotación

Un elemento relevante de la respuesta de Google es la comprobación realizada sobre los registros públicos de Certificate Transparency o CT.

Google indica que, antes del bloqueo de los certificados intermedios afectados, no existían certificados TLS registrados que encadenaran con las seis autoridades intermedias comprometidas.

Chrome exige, de forma predeterminada, el cumplimiento de sus requisitos de Certificate Transparency para certificados públicamente confiables.

En consecuencia, los certificados fraudulentos no registrados no habrían sido aceptados por defecto por Chrome antes de que se distribuyera el bloqueo.

Esta circunstancia reduce significativamente el riesgo para navegadores y aplicaciones que aplican correctamente los requisitos de CT.

Sin embargo, no todos los clientes TLS utilizan los mismos mecanismos de transparencia, revocación o actualización de confianza.

Por ello, la ausencia de certificados fraudulentos en los registros CT no permite descartar por completo el riesgo para aplicaciones, dispositivos o sistemas que no aplicasen estas protecciones.

Riesgo residual en aplicaciones y sistemas que gestionan sus propios certificados
Aunque los principales fabricantes han reaccionado rápidamente, la protección no depende exclusivamente de los navegadores web.

Existen aplicaciones empresariales, bibliotecas criptográficas, dispositivos de red, sistemas industriales, soluciones integradas y servicios que utilizan almacenes de certificados independientes o que no reciben automáticamente las actualizaciones de confianza distribuidas por los fabricantes.

En estos entornos, una autoridad de certificación comprometida podría continuar siendo reconocida como válida hasta que se actualice el almacén correspondiente o se aplique una medida equivalente de desconfianza.

Esto obliga a prestar especial atención a los sistemas que utilizan versiones antiguas de bibliotecas TLS, almacenes de confianza mantenidos manualmente o componentes que no disponen de mecanismos centralizados de revocación.

También deben revisarse los servicios propios cuyos certificados dependan de emSign ECC Root CA - G3, dado que la retirada de esta autoridad de determinados almacenes puede provocar errores de validación y problemas de disponibilidad.

La respuesta debe equilibrar la retirada de confianza en los certificados comprometidos con la continuidad de los servicios legítimos que puedan verse afectados.