El 17 de octubre de 2026 un investigador demostró que los certificados eMudhra comprometidos incluyen ocho intermedios cuyas claves privadas eran tan débiles que cualquiera podía recuperarlas. Mozilla recibió el aviso a las 20:06 UTC y en menos de tres horas Firefox ya había bloqueado los certificados afectados a través de OneCRL. Chrome actuó el mismo día, Apple el 19 y Microsoft el 20. El incidente, que salió a la luz pública el 20 de octubre, expone una vez más la fragilidad de la cadena de confianza de la web: un error en la generación de claves de una sola CA puede poner en riesgo a millones de usuarios.
Qué ocurrió exactamente
La autoridad eMudhra Limited, que opera bajo la marca emSign, emitió ocho certificados intermedios cuyas claves privadas resultaron ser extremadamente débiles. Según el análisis técnico publicado por investigadores y recogido por Ars Technica, las claves elípticas P-384 deberían tener alrededor de 384 bits de entropía. En su lugar, las claves comprometidas contenían apenas entre 3 y 8 bits. Sus valores enteros eran tan pequeños (4, 56, 66, 115, 155, 156, 230 y 237) que cualquiera con conocimientos básicos de criptografía podía recuperarlas en segundos. El investigador que se identificó como Wayne demostró el control de las claves firmando el mensaje «We have a problem here – Wayne» con cada una de ellas y lo envió a los programas de raíces de Chrome, Mozilla, Apple y Microsoft el 17 de octubre. Mozilla confirmó de forma independiente la recuperación de las claves en menos de dos horas, sin conocer el método exacto utilizado por el reportero original. El sitio de divulgación emudhra.we-have-a-problem.com, publicado por Dennis Jackson, recoge los certificados, las claves públicas y las firmas para que cualquiera pueda verificar el compromiso.
Los ocho intermedios cuelgan de raíces de confianza incluidas en los almacenes de Mozilla, Microsoft, Apple y Chrome. Seis son para TLS (Domain Validated, Organization Validated y Extended Validation) y dos para firma de código. eMudhra revocó los certificados con el código de razón cACompromise el 18 y 19 de octubre. Sectigo, que había cross-firmado algunos de ellos, también revocó esas firmas. Hasta el momento no hay indicios en los registros de Certificate Transparency de que se hayan emitido certificados maliciosos con esas claves, pero el riesgo existe para cualquier cliente que aún no haya actualizado su almacén de confianza.
Por qué las claves eran tan débiles
El fallo no es un robo clásico de una clave bien generada. Es un error de generación de claves de proporciones extraordinarias. Filippo Valsorda, ingeniero de criptografía y mantenedor de la librería de Go, lo calificó de «bonkers» y lo comparó en escala de limpieza con Heartbleed, el famoso fallo de OpenSSL de 2014. «Hay más contextos, más personas y más heterogeneidad», explicó. Ben Cartwright-Cox, director de BGP.tools, sugirió que podría tratarse de código de ejemplo que se filtró a producción. Mozilla pudo recuperar las claves por sí misma, lo que confirma que el proceso de generación de eMudhra era defectuoso y trivial de explotar. El bug de Mozilla 2083449 documenta que «las claves privadas P-384 de 8 intermedios de eMudhra son enteros minúsculos y pueden recuperarse casi al instante».
Este tipo de fallo recuerda que las autoridades de certificación no solo deben cumplir políticas de emisión y revocación, sino también garantizar la calidad criptográfica de sus propias claves. eMudhra ya había tenido varios incidentes de cumplimiento en el pasado, entre ellos retrasos en la publicación de certificados en el CCADB y problemas con mecanismos de bloqueo de claves. El incidente actual, sin embargo, es de una naturaleza distinta: no es un retraso administrativo, sino una rotura fundamental de la seguridad de las claves.
La respuesta de los navegadores y del ecosistema
La velocidad de la respuesta fue notable. Mozilla recibió el aviso el sábado 17 a las 20:06 UTC y completó el despliegue de OneCRL a las 22:59 UTC. Los usuarios de Firefox con configuraciones estándar quedaron protegidos sin necesidad de reiniciar el navegador. El 20 de octubre Mozilla publicó además Firefox 158.0.1, las ESR 115.43.1 y 153.5.1, y actualizó NSS a la versión 3.131.1 para eliminar la raíz que firmaba los intermedios afectados. Chrome bloqueó los certificados el mismo 17 mediante CRLSets. Apple lo hizo el 19 y Microsoft el 20. Go publicó las versiones 1.27.3 y 1.26.10 con el parche CVE-2026-111943, que rechaza cualquier cadena que contenga uno de los ocho SPKI comprometidos. Python certifi, curl y varias distribuciones de Linux también han emitido actualizaciones o están en proceso de hacerlo.
El sitio de divulgación recomienda a los usuarios actualizar navegadores y sistemas operativos lo antes posible. Quienes quieran comprobar si su cliente aún confía en los certificados pueden visitar las subdominios de prueba de emudhra.we-have-a-problem.com. Si la conexión falla con un error de certificado, el bloqueo está funcionando. Filippo Valsorda advirtió que la cola de limpieza será larga: dispositivos IoT, contenedores Docker antiguos, herramientas de línea de comandos que incluyen sus propias raíces y máquinas Linux olvidadas seguirán vulnerables durante meses o años.
Qué implica para los usuarios en España
Para la mayoría de los usuarios españoles que navegan con Chrome, Firefox, Safari o Edge actualizados, el riesgo práctico es ya muy bajo. Los navegadores principales han distribuido los bloqueos de forma automática. El problema se concentra en clientes que no consultan listas de revocación en tiempo real, en aplicaciones que usan almacenes de confianza propios o en sistemas embebidos que no reciben actualizaciones frecuentes. En entornos corporativos españoles es habitual encontrar servidores internos, proxies y herramientas de desarrollo que dependen de almacenes de certificados desactualizados. Un administrador de sistemas que no aplique los parches de Go, Python o de las distribuciones de Linux podría aceptar conexiones TLS firmadas con las claves comprometidas.
El impacto real requiere un ataque de intermediario activo: el atacante debe situarse entre el usuario y el servidor, interceptar el tráfico, presentar un certificado falso firmado con una de las claves débiles y reenviar el tráfico. En una red Wi-Fi pública, en un proxy corporativo mal configurado o en un país con capacidades de interceptación masiva, esa condición se cumple con más facilidad. No hay informes de explotación activa, pero la ventana de exposición para sistemas no actualizados permanece abierta. Las empresas españolas que utilizan certificados de eMudhra o de Sectigo (que cross-firmó algunos intermedios) deben revisar sus inventarios de certificados y confirmar que ningún certificado de hoja vigente depende de las cadenas afectadas.
Qué deben hacer desarrolladores y administradores
Los desarrolladores que usan Go deben actualizar a 1.27.3 o 1.26.10 y recompilar sus binarios. Los que dependen de Python deben asegurarse de que certifi está en la versión 2026.10.19 o superior. En sistemas Linux, las actualizaciones de ca-certificates de Ubuntu, Debian, Arch y otras distribuciones ya están disponibles o en camino. Es recomendable probar las herramientas de línea de comandos (curl, wget, openssl) contra los hosts de prueba del sitio de divulgación. En entornos de contenedores, las imágenes base deben reconstruirse con almacenes de confianza actualizados. Las organizaciones que gestionan su propio almacén de confianza (por ejemplo, mediante sistemas de gestión de certificados empresariales) deben añadir los SPKI comprometidos a sus listas de desconfianza.
Para los usuarios finales la recomendación es simple: mantener navegadores y sistemas operativos actualizados. Firefox, Chrome, Safari y Edge ya han aplicado las protecciones. Quienes usen versiones antiguas o configuraciones personalizadas que desactiven las actualizaciones automáticas de listas de revocación deben revisarlas. El incidente también sirve de recordatorio de que la confianza en la web depende de un número relativamente pequeño de autoridades de certificación. Cuando una de ellas falla en algo tan básico como la generación de claves, el coste de la limpieza recae en todo el ecosistema.
Qué viene ahora
Mozilla ha indicado que compartirá más información cuando las circunstancias lo permitan. eMudhra aún no ha publicado un informe de incidente detallado. El bug de Mozilla sigue abierto y la comunidad de seguridad continúa analizando el alcance exacto de los certificados emitidos bajo esas cadenas. La limpieza de la cola larga —dispositivos IoT, sistemas embebidos y herramientas antiguas— llevará tiempo. Mientras tanto, el caso ilustra dos lecciones claras. La primera es que los mecanismos de respuesta rápida de los navegadores (OneCRL, CRLSets, actualizaciones de NSS) funcionan y pueden proteger a la mayoría de los usuarios en cuestión de horas. La segunda es que la calidad criptográfica de las claves de las autoridades de certificación sigue siendo un punto débil del modelo de confianza de la web. Un error de generación que debería haber sido imposible ha obligado a una movilización global. Para los usuarios en España, la prioridad inmediata es actualizar. Para el ecosistema, el trabajo de fondo apenas comienza.
Deja una respuesta