📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
El sábado 17 de octubre un investigador avisó a Apple, Google, Microsoft, Mozilla y a la autoridad certificadora eMudhra de algo que no debería ser posible: ocho certificados intermedios de eMudhra tenían claves privadas que cualquiera podía recuperar en menos de un segundo. Una de esas claves era, literalmente, el número 4. Otra el 56, otra el 115. No una clave que empiece por 4 seguida de cientos de dígitos aleatorios: el número 4.
El detalle técnico es corto. Estas claves son de curva elíptica P-384: la clave privada es solo un número, y la pública se calcula multiplicándolo por un punto fijo de la curva. Toda la seguridad depende de que ese número sea aleatorio y enorme, de 384 bits. En estos ocho certificados el número privado tenía 47 bytes de ceros y un único byte con datos: 256 posibilidades. Recuperarlo es probar punto por punto hasta que calza, máximo 255 pasos. Scott Helme recorrió los 16 certificados publicados por Mozilla y los ocho cayeron al instante en su laptop; después contó que bastó un solo prompt a un agente de IA para repetir el resultado.
¿Y cómo una CA termina con claves así? Según eMudhra, un bug en el script de la ceremonia de generación creó un par de claves débiles dentro del HSM y, por nombres parecidos, un error humano usó esas al firmar el CSR. La criptografía aguantó perfecta: P-384 sigue intacta. Lo que falló fue el proceso humano alrededor. Chrome bloqueó los intermediarios la misma noche del reporte, Mozilla lo hizo público el 20 de octubre y sacó el root de Firefox, y hoy 22 de octubre eMudhra anunció que abandona el negocio global de certificados SSL/TLS, cerca del 1% de sus ingresos.
El problema de verdad: todo lo que no es tu navegador
Aquí lo que me importa como admin de servidores. Chrome, Firefox y Safari están probablemente bien: bloquean los intermediarios y exigen Certificate Transparency. Pero el resto del mundo TLS no revisa revocación ni CT por defecto: curl, Python, Node, Go, Java, git, pip y cada cron job que corre en un servidor confían en un bundle de CA en disco y ya. Scott lo demostró de la peor forma: generó un certificado forjado para api.stripe.com firmado por el intermediario comprometido y, con configuración por defecto, curl respondió SSL certificate verify ok, Python completó el handshake y Node contestó authorized: true.
Más incómodo: nadie tuvo que robar nada. Las claves eran públicas desde que los certificados existieron, en abril de 2025. Eso deja una ventana de exposición de unos 17 meses y no hay forma de saber si alguien la aprovechó. Los navegadores exigen CT y ningún certificado encadenado a estos CAs apareció en los logs, lo cual reconforta; pero CT detecta mala emisión, no la previene, y la mayoría del software que no es navegador ni lo consulta.
Lo que toca hacer
La parte remediable es aburrida y no admite excusas: actualizar el paquete ca-certificates del sistema, el bundle de certifi de Python y los bundles de Node, y reconstruir las imágenes de contenedor cuando las base se actualicen. En mi flota fueron unos minutos por máquina; lo importante es no dejarlo, porque los bundles viejos siguen considerando confiables estos certificados hasta 2039, su fecha de expiración.
La parte incómoda no tiene remedio: routers, impresoras, cámaras y firmware congelado seguirán confiando en estos CAs hasta que expiren. Ahí es donde «no se puede contener» deja de sonar a titular. Ese firmware que actualizas cada cinco años si acaso es justo el tipo de cliente que no revisa revocación, no conoce CT y depende del bundle de fábrica.
La lección que me queda es de proceso, no de criptografía. Una CA es una organización con scripts, ceremonias, HSMs y humanos cansados, y toda la confianza de HTTPS descansa en esa cadena de gente con pega. Ocho bits. Durante 17 meses eso fue todo lo que separó a miles de servidores de un certificado forjado para cualquier dominio, mientras los algoritmos de abajo funcionaban perfectamente. La próxima vez que alguien te diga que la seguridad es cuestión de algoritmos fuertes, recuerda que la clave privada podía ser el número 4.
Fuente del tema: Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds (Scott Helme).
Fuente de inspiración: Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds
