eMudhra: la certificadora cuyas claves cabían en un número

Cuando entras a tu banco, el navegador recibe un certificado que dice «este servidor es el de tu banco». Ese certificado lo firma una autoridad de certificación. El navegador confía en la firma porque esa autoridad está en su lista de confianza, el llamado almacén raíz.

En la práctica hay una cadena: un certificado raíz, muy protegido, firma certificados intermedios, y los intermedios firman los certificados de los sitios. Quien tenga la clave privada de un intermedio de confianza puede fabricar un certificado válido para cualquier dominio del mundo: tu banco, tu correo o tu tienda.

Por eso la clave privada de un intermedio tiene que ser un número aleatorio enorme, de más de cien dígitos, imposible de adivinar.

Según Help Net Security, las ocho claves afectadas eran números menores que 256. Para encontrar cualquiera bastaba con probar como máximo 256 valores, algo que un computador hace en una fracción de segundo. El investigador Scott Helme recuperó claves como 4, 56 y 115. Qualys estima que la entropía efectiva de esas claves P-384 era de entre 3 y 8 bits, cuando debería ser de cientos.

El origen está en una ceremonia de generación de claves del 30 de abril de 2025, en la que eMudhra creó 24 certificados intermedios. Un script defectuoso generó un segundo juego de claves débiles con etiquetas parecidas a las buenas, y el personal eligió las equivocadas. De las ocho afectadas, seis eran para sitios web (TLS) y dos para firma de código.

eMudhra admite errores humanos en varios pasos. Asegura que solo uno de los ocho intermedios llegó a producción, que ninguno emitió certificados a clientes y que su infraestructura no fue vulnerada. Lo que nadie puede asegurar es si alguien encontró y usó esas claves en los 17 meses que pasaron entre la ceremonia y el descubrimiento.

Desde hace años, Chrome exige que cada certificado de sitio web se publique en registros públicos llamados Certificate Transparency antes de aceptarlo. Google comprobó que no había ningún certificado encadenado a los intermedios afectados en esos registros antes del bloqueo.

Eso significa que, aunque alguien hubiera fabricado un certificado falso, Chrome y las aplicaciones Android recientes lo habrían rechazado por no estar registrado. Es un ejemplo poco frecuente de una protección diseñada hace una década funcionando exactamente como se esperaba.

Los navegadores se actualizaron en horas. El resto del software no. Las aplicaciones de servidor, los scripts que se conectan a una API, los contenedores Docker, los teléfonos sin actualizar y muchos equipos embebidos traen su propia lista de autoridades de confianza, y esa lista no se actualiza sola.

Mientras no se actualice, ese software sigue confiando en los intermedios comprometidos. Un atacante en posición de interceptar el tráfico — una red wifi pública, un router comprometido — podría hacerse pasar por cualquier servicio ante él. Scott Helme lo resumió advirtiendo que eso podría exponer datos de usuarios a cualquiera que pueda interceptar el tráfico.

Lo que hay que actualizar, y cómo comprobarlo, está en nuestro artículo sobre qué revisar en tus servidores después del caso eMudhra.

Hay dos lecturas. La pesimista: una sola empresa entre decenas, por un error humano en un script, puso en riesgo la confianza de todo internet durante 17 meses sin que nadie lo notara. La optimista: cuando se descubrió, los cuatro grandes navegadores actuaron en tres días, la transparencia de certificados evitó el peor escenario y la empresa responsable salió del mercado.

Las dos son ciertas. Y explican por qué la industria lleva años empujando hacia certificados de vida más corta y renovación automática: cuanto menos dura un certificado, menos daño hace uno que salga mal.