El candado que aparece junto a la dirección de una web parece algo sencillo, pero depende de una cadena de confianza que casi nadie ve. A mediados de octubre de 2026 uno de sus eslabones resultó estar roto de una forma que los expertos han calificado de casi absurda. Un investigador independiente descubrió que ocho certificados intermedios emitidos por eMudhra, una autoridad de certificación con sede en la India, tenían claves privadas tan pequeñas que bastaba con probar unos pocos valores para dar con ellas. Según Cisco Talos y Cloudflare, quien tuviera una de esas claves podía fabricar certificados válidos para cualquier dominio de internet.

Cómo funciona la cadena de confianza

Cuando entras en una web cifrada, tu navegador recibe un certificado que dice algo así como «este servidor es de verdad tal dominio». Para creérselo comprueba quién firma ese certificado. Lo normal es que lo firme un certificado intermedio, que a su vez está firmado por un certificado raíz. Las raíces vienen preinstaladas en el navegador y en el sistema operativo, y ellos confían en ellas de antemano.

Los intermedios existen para no tener que sacar la raíz de su caja fuerte cada vez que hay que firmar algo, pero tienen el mismo poder práctico: un intermedio de confianza puede firmar certificados para cualquier sitio. Por eso su clave privada es de las cosas que más se protegen en internet. Normalmente se genera y se guarda dentro de módulos de seguridad de hardware (HSM), unos dispositivos diseñados para que la clave no salga nunca de ellos.

Qué falló exactamente

Los ocho certificados usaban criptografía de curva elíptica (P-384). En este sistema la clave privada es, en el fondo, un número enorme, elegido al azar entre una cantidad astronómica de posibilidades. La seguridad depende de que sea imposible adivinarlo. Pero según el informe de incidente de Mozilla, citado por Help Net Security, todas esas claves eran menores que 256. Cualquiera podía sacarlas a partir de los certificados públicos en menos de un segundo. El investigador británico Scott Helme lo resumió así:

«Una de las claves privadas de autoridad de certificación de eMudhra es el número 4.» (Scott Helme, citado por Help Net Security)

Google habla de claves generadas con «aleatoriedad insuficiente». eMudhra asegura que usó HSM certificados y atribuye el problema a un error en un script durante la ceremonia de generación de claves del 30 de abril de 2025: se creó un segundo juego de claves débiles con etiquetas parecidas a las buenas, y fueron esas las que acabaron publicadas. La empresa dice que la causa raíz aún no está confirmada del todo y que el fallo pasó desapercibido unos 18 meses, a lo largo de dos ciclos de auditoría.

De los ocho intermedios, seis servían para firmar certificados web y dos para firmar código. eMudhra sostiene que solo uno llegó a estar en producción y que no emitió ningún certificado a clientes.

La respuesta: horas, no semanas

Lo más llamativo del caso fue la rapidez de la respuesta. El aviso llegó el 17 de octubre y ese mismo día pasó esto:

• Chrome envió una actualización de su lista de bloqueo (CRLSet) que vetaba esas claves sin necesidad de actualizar ni reiniciar el navegador. Android recibió una protección equivalente a través de los servicios de Google Play.
• Firefox bloqueó los certificados mediante OneCRL, su lista de revocación, y después publicó versiones corregidas.
• Según Help Net Security, Apple actuó el 19 y Microsoft el 20 de octubre. eMudhra revocó los ocho certificados el día 18.

Además, Mozilla retiró la raíz afectada y Google anunció que quitaría «emSign ECC Root CA - G3» de Chrome a partir del 27 de octubre. Herramientas como el lenguaje Go y los clientes de Cloudflare también se actualizaron para rechazar esas cadenas. El 22 de octubre eMudhra anunció que dejaba el negocio mundial de certificados TLS. Según la compañía, unos 30.000 certificados de clientes tendrán que cambiarse a otro proveedor.

La letra pequeña

Google explica que no se registró ningún certificado web firmado por esos intermedios en Certificate Transparency, el registro público donde deben anotarse los certificados. Así, los clientes que exigen ese registro, como Chrome, no podían caer con un certificado falsificado. Pero que nadie lo haya usado en público no prueba que nadie lo usara en privado. Help Net Security recuerda que no se sabe si alguien aprovechó las claves en los meses previos al aviso.

El riesgo que queda está en lo que no se actualiza: aplicaciones con su propio almacén de certificados, contenedores con imágenes antiguas, dispositivos conectados o servidores que nunca reciben listas de revocación. Cloudflare pide a los desarrolladores mirar «debajo del SDK» para ver de dónde sale realmente la confianza, y sobre todo no apagar la verificación de certificados para quitarse de encima los errores que aparezcan.

Para el usuario medio la receta es sencilla: tener el navegador y el sistema operativo al día. Quien administre sistemas debe revisar sus almacenes de certificados, reconstruir imágenes y reiniciar servicios.

Por qué importa

La seguridad de la web descansa en unos pocos cientos de organizaciones a las que todos los dispositivos dan confianza ciega. Este caso enseña las dos caras de ese sistema. Por un lado, un error humano en una sola ceremonia de claves puso en peligro, en teoría, cualquier web del planeta, y ni las auditorías lo detectaron. Por otro, las herramientas que se han ido sumando con los años (listas de bloqueo que se actualizan en minutos, registros públicos de certificados, programas de raíces que pueden expulsar a una autoridad) permitieron cortar el problema en cuestión de horas. La lección práctica no ha cambiado: actualizar no es opcional.