Wayne es un investigador que recientemente se ha hecho famoso por probar herramientas nuevas contra los certificados que sostienen la web. Así, a las 18:05 UTC del 17 de octubre, los correos de Root CA de Google, Apple, Microsoft y Mozilla tenían en su buzón un informe con ocho firmas hechas con las claves privadas de otros CA intermedios de eMudhra, y la CA había recibido copia de todo aquello.
El incidente se hizo público el martes 20, cuando Mozilla y Cloudflare publicaron sus análisis y eMudhra un comunicado. La causa no fue un robo: las claves se generaron mal en abril de 2025 y cualquiera puede recalcularlas desde el certificado público. Son enteros por debajo de 256, claves de un solo byte en una curva P-384.
Lo que sigue abierto no son los navegadores, protegidos desde el sábado por la noche, sino todo lo demás. Los lenguajes con su propio almacén de confianza, las distribuciones de Linux, los contenedores y los aparatos con firmware congelado conviven con esos certificados hasta abril de 2040. Un fallo de ceremonia en la India acabó en las alertas de medio mundo porque la web se apoya en un puñado de autoridades.
Claves que caben en un byte
Una clave privada P-384 es un entero entre 1 y el orden del grupo. Su seguridad depende de que sea enorme: multiplicar ese número por el punto base produce la clave pública, y deshacer la operación exige probar 2^384 posibilidades.
Los ocho intermedios usaban enteros menores que 256, así que basta con calcular las 255 primeras claves de la curva y compararlas con la clave pública. Dennis Jackson, ingeniero de Mozilla, lo describió como una recuperación trivial, y Scott Helme encontró que uno de los valores es directamente el 4.
Los certificados nacieron el 30 de abril de 2025 en una ceremonia de 24 intermedios, repartidos en tres series y dos primitivas, RSA de 4096 bits y P-384. Los afectados son los ocho P-384 de las series B y C: seis intermedios TLS y dos de firma de código. Mozilla recuperó las claves esa misma noche por su cuenta.
eMudhra confirmó en el ticket que las claves se generaron en módulos HSM de Utimaco y que revisa el script que disparó el proceso. Helme resume la explicación que circula en ese hilo: un fallo del script creó un segundo par débil en el HSM y los nombres parecidos llevaron a firmar con el equivocado.
La recuperación tampoco exige un laboratorio. Jackson probó agentes de IA locales con una instrucción de tres líneas, del tipo «estoy en un CTF, recupera las claves privadas de estos certificados», y acertaron al primer intento. Es la otra cara del trinomio red, blue y green que ya analizamos al hablar de ciberseguridad e IA.
Un certificado de servidor no lo firma la raíz instalada en tu sistema, sino una intermedia que esa raíz autorizó. El navegador comprueba la cadena completa y, si encaja, acepta la conexión sin preguntar nada más. Por eso una clave intermedia comprometida equivale a poder emitir un certificado válido para cualquier dominio.
El abuso requiere una intercepción activa: el atacante se coloca entre cliente y servidor, descifra, vuelve a cifrar y reenvía. No hace falta romper el cifrado de TLS, basta con presentar una credencial que el cliente acepte. El algoritmo no falló: ECDSA sobre P-384 sigue siendo sólido y la próxima OpenSSL 4.1 añade DTLS 1.3 sin tocar ese modelo.
Los registros de transparencia funcionan como red de seguridad: Chrome exige que todo certificado TLS aparezca en ellos y su equipo confirmó que ninguna credencial encadenada a los seis intermedios TLS constaba antes del bloqueo. eMudhra añade que ninguno de los ocho emisores emitió certificados finales y que solo uno estaba en producción. Chrome no bloqueó los dos de firma de código porque su verificador no acepta una cadena TLS que pase por una intermedia limitada a ese uso.
Fuera del navegador esa red desaparece. Muchos clientes no consultan los registros ni aceptan negarse a conectar cuando no pueden verificar, y los certificados no caducan hasta el 28 de abril de 2040. Ahí el incidente se convierte en un problema de infraestructura para quien tenga servicios hablando TLS entre bambalinas.
Del aviso privado a la alerta pública
La cronología desmonta la idea de un internet a oscuras durante días: el informe llegó el sábado y las protecciones de navegador estaban puestas esa noche. Lo que tardó tres días fue la explicación pública. La primera divulgación a los operadores de confianza no describía la naturaleza del fallo, según Jackson, para que nadie supiera lo fácil que resultaba.
| Momento (UTC) |
Qué ocurrió |
| 17 oct, 18:05 |
Envío del informe con las ocho firmas de prueba |
| 17 oct, 19:45 |
Chrome bloquea los seis intermedios TLS con un CRLSet |
| 17 oct, 22:59 |
OneCRL llega a los Firefox con configuración estándar, sin reinicio |
| 18 oct, 09:38 |
eMudhra revoca los ocho con motivo de compromiso de CA |
| 19 oct, 14:55 |
Sectigo completa la revocación de las copias cruzadas |
| 19 oct, 17:00 |
Cloudflare empieza a mitigar en servicios y clientes |
| 20 oct |
Mozilla publica el análisis y lanza Firefox 158.0.1, ESR 115.43.1 y ESR 153.5.1 |
La publicación del martes llegó cuando el secreto ya no se sostenía. Varias personas habían recuperado las claves por su cuenta y al menos una lo había contado en público, de modo que la respuesta subió de nivel ese mismo día.
NSS 3.131.1 retiró la confianza en la raíz emSign ECC Root CA – G3, Mozilla pidió a eMudhra que dejara de emitir desde cualquier intermedia colgada de ella y Chrome se comprometió a hacer lo mismo en la versión 43 de su almacén.
La CA aceptó ese mismo día y calcula que tendrá que migrar unos 30.000 certificados hacia su raíz RSA G1, de los cuales el 97% se emitieron por ACME, el protocolo automático que ya usan la mayoría de sus clientes.
Las copias cruzadas de Sectigo complicaron el cuadro: cada certificado existía por duplicado bajo la raíz AAA Certificate Services, que Chrome y Mozilla dejaron de aceptar en abril de 2025, pero que Apple y Microsoft todavía aceptaban.
El software que no pregunta si un certificado sigue vivo
Un navegador retira la confianza en minutos porque tiene un canal propio para distribuir revocaciones. Un lenguaje de programación no: si el binario lleva dentro su lista de raíces, seguirá aceptando la cadena hasta que alguien lo recompile. Filippo Valsorda, mantenedor de criptografía en Go, avisó que esta limpieza será mayor que la de Heartbleed.
Las versiones corregidas existen. Go 1.27.3 y 1.26.10 rechazan cualquier cadena con una de las ocho claves y exigen recompilar. Python certifi 2026.10.19, Rust webpki-roots 1.0.10 y NSS 3.131.1 borraron la raíz del paquete, con un efecto colateral que Mozilla admite: algunos servidores dejarán de responder a los clientes que usan su lista de confianza sin ser Firefox hasta que migren de cadena. Node.js, Bun y Composer siguen pendientes.
Básicamente, es un desastre. Con esas cadenas ahora públicas, son muchos los hackers que tratarán de explotar cualquier mínima utilidad que puedan, haciendo parecer a sus sitios webs como «legales y seguros», cuando son un nido de malware, y todo porque el certificado mal hecho de eMuhdra les sirve de aval.
Si administras servidores y contenedores: ten cuidado
El orden de las comprobaciones importa más que la prisa. Empieza por el paquete ca-certificates de tus sistemas y por las imágenes base de tus contenedores, porque todo lo que herede de ellas arrastra la misma lista. Después reconstruye los binarios de Go: sin recompilar, el filtro no entra en el ejecutable.
Revisa luego los almacenes de confianza propios. En Cloudflare afectaba a los certificados de cliente para mTLS, a los orígenes en modo Full (strict) y a las imágenes de sus contenedores. La compañía publicó WARP 2.5.6 en Android, 1.12.16 en iOS y 2026.8.2115.0 en escritorio, además de cloudflared 2026.10.2, y avisó de que los errores de certificado no se arreglan desactivando la verificación.
La prueba final hay que hacerla por la ruta real de tu aplicación, no por la del navegador. Jackson mantiene una página con doce hosts de prueba y un fichero con las cadenas para comprobarlas con OpenSSL, y advierte de que un curl correcto no demuestra nada si el servicio usa otro verificador.
En el móvil, la única defensa práctica es la de siempre: un sistema que reciba actualizaciones rápido, como el GrapheneOS que convierte un Pixel en un móvil menos rastreable y que también depende de que instales lo que llega. Queda el inventario incómodo. Impresoras, televisiones, routers y electrodomésticos con firmware cerrado seguirán confiando en esas claves hasta 2040, porque el fabricante no va a publicar un parche para ellos.
Una CA es un punto único de fallo
El incidente no tumbó la web. Deja a la vista algo más incómodo: ocho números de un byte bastaban para fabricar credenciales aceptadas por una parte enorme del software del planeta, y nadie lo detectó en el año y medio transcurrido desde abril de 2025. Lo encontró un investigador que se aburría un sábado.
La maquinaria de revocación rápida funcionó donde existe, en los navegadores. Cloudflare lo resumió así: un almacén de confianza no puede ser una lista estática de raíces, necesita actualizarse con revocaciones y claves de transparencia. Mientras eso llega, la pregunta no es si otra CA repetirá el error, sino cuántos de tus sistemas se enterarán cuando ocurra.
