Mientras medio sector miraba hacia el robo de Binance, Microsoft cerraba el 26 de octubre una de las peores crisis de confianza de la historia reciente de la criptografía aplicada. Dos actualizaciones fuera de banda, identificadas como KB5134133 y KB5134125, retiran siete certificados de la lista de confianza de Windows por su relación con las claves comprometidas de la autoridad certificadora india eMudhra. No es la retirada de un certificado caducado más: es el reconocimiento de que ocho claves privadas intermedias se generaron con valores que se pueden probar por fuerza bruta.
El detalle técnico explica la urgencia. Las ocho claves se crearon en abril de 2025 y sus valores estaban por debajo de 256, un rango que se recorre probando 256 números posibles. Un atacante que conozca el algoritmo y el momento de generación puede reconstruir la clave privada sin criptografía cuántica, sin una granja de GPU y sin acceso físico al servidor que la guardaba. El origen de la crisis está en los ocho certificados comprometidos que obligaron a los navegadores a mover ficha en tiempo récord.
La retirada afecta a Windows 11 en sus versiones 24H2, 25H2 y 26H2 a través de KB5134133, y a Windows 10 en 21H2 y 22H2 a través de KB5134125. Son actualizaciones pensadas para equipos que no pueden esperar a que la lista de confianza se refresque por Internet, es decir, servidores aislados o redes con actualizaciones automáticas desactivadas. Ese detalle importa más de lo que parece, porque el parche no llega solo.
¿Qué se retira exactamente y qué queda?
Microsoft había actualizado antes su lista de certificados no permitidos, que bloquea ocho autoridades intermedias de eMudhra: seis para TLS y dos para firma de código. También publicó una actualización de la lista de revocación para Edge y WebView2. El movimiento del 26 de octubre va un paso más allá y retira de la lista de confianza de Windows siete certificados: seis raíces eMudhra G3 y una firma cruzada de AAA Certificate Services.
La firma cruzada es la pieza que suele pasar desapercibida y la que más rompe. Una raíz cruzada hereda la confianza de otra raíz, de modo que si la cadena de AAA valida a eMudhra, cualquier certificado emitido bajo esa jerarquía se acepta como legítimo. Retirar la cruzada obliga a Microsoft a tocar dos árboles en lugar de uno, y explica por qué la actualización llegó después del bloqueo de intermedias.
Edge siguió el mismo camino un día más tarde, con la retirada prevista para el 27 de octubre. Ahí el riesgo es distinto: el navegador usa su propia lista y no depende de la del sistema, así que un equipo puede tener Windows actualizado y Edge desactualizado, o al contrario. En una flota corporativa con varios canales de despliegue, esa diferencia se convierte en una semana de soporte.
Para quien administra sistemas desconectados, la recomendación de Microsoft es directa: instalar la actualización, revisar qué certificados dependen de las raíces retiradas y sustituirlos. Suena mecánico hasta que se descubre que muchas aplicaciones internas firmadas con eMudhra no tienen sustituto inmediato y que el departamento de compras ya no sabe quién emitió la clave en 2022.
El problema de las claves débiles va más allá de TLS
El hallazgo de fondo no es que una autoridad certificadora haya tenido un incidente. Es que una CA puede generar claves privadas con valores predecibles y que ese error sobreviva casi dos años hasta que alguien lo nota. En el resto de la industria, la generación de claves de auditoría con controles formales y con verificaciones de entropía, pero los informes de auditoría no siempre miran el código que produce los números.
La comparación con el caso de certificados Secure Boot de Windows que caducan este año es inevitable, aunque las causas sean opuestas. Allí el problema es el calendario y la dependencia de material antiguo. Aquí es la calidad del material criptográfico que se emitió ayer mismo. Las dos rutas llevan al mismo sitio: cadenas de confianza largas, con eslabones que nadie revisa hasta que falla el último.
Cloudflare publicó un seguimiento de explotación real y su conclusión merece atención. Los navegadores están protegidos porque actualizaron sus listas rápido, pero el tráfico de máquina a máquina, las llamadas entre servicios y los dispositivos industriales siguen confiando en cadenas que nadie ha tocado. Ese es el inventario que hay que buscar, y no aparece en el panel de Windows Update.
¿Cómo revisar tu propia cadena de confianza?
La revisión se puede hacer en una tarde con herramientas del sistema. En Windows, el complemento de certificados del panel de control permite ver las raíces y las intermedias instaladas, y basta con filtrar por el nombre de la autoridad para saber si quedan restos. En sistemas Linux el inventario está en el almacén del sistema y en los paquetes de cada aplicación, que es donde suelen esconderse las sorpresas. La decisión de la autoridad de abandonar el negocio global de TLS dejó a miles de clientes buscando sustituto con el calendario en contra.
La segunda capa es el inventario propio. Cualquier servicio que valide certificados de servidores internos debe comprobar si confía en una raíz eMudhra por configuración explícita en lugar de por el almacén del sistema. Los proxies corporativos y las pasarelas de pago son los dos sitios donde aparece con más frecuencia.
La tercera es el calendario. Si un certificado emitido bajo esa jerarquía sigue en uso, la fecha de caducidad deja de ser una guía útil: hay que rotarlo aunque tenga validez hasta 2028. Un certificado firmado con una clave predecible es un certificado comprometido aunque su ventana de validez diga lo contrario. El caso de Fedora 45 y su retraso por el mismo certificado enseña cuánto tarda una distribución en rehacer su cadena completa.
Lo que dice el silencio de eMudhra
La autoridad certificadora revocó los ocho certificados intermedios y después anunció su retirada del negocio global de TLS. Las autoridades de navegador, Mozilla, Google y Apple, coordinaron la desconfianza con margen de días. Lo que no ha llegado es una explicación técnica pública sobre cómo se generaron esas claves y qué control falló.
Ese silencio tiene consecuencias prácticas. Sin una causa documentada, los clientes de eMudhra no saben si el problema afecta solo a las ocho claves conocidas o a un proceso de generación más amplio. Y las autoridades de navegador tampoco pueden evaluar si la retirada es suficiente o debería extenderse a otros productos de la misma casa.
Para el mercado de certificados europeo la lectura es incómoda. La diversificación de autoridades fue una recomendación de los últimos años, y el resultado es un ecosistema con más raíces, más intermedias y más dependencias cruzadas que nadie mapea por completo. Cada retirada de emergencia como esta paraliza servicios que no se pueden inventariar rápido.
¿Por qué la confianza tarda más en volver que en irse?
Un navegador puede dejar de confiar en una autoridad en cuarenta y ocho horas. Recuperar la confianza de los clientes lleva años y requiere auditorías independientes que no siempre se publican. En ese desequilibrio vive el negocio de las autoridades certificadoras, y también su fragilidad.
La lección operativa de esta semana es que la seguridad de la cadena no depende de la raíz que ves en la barra de direcciones. Depende de ocho claves intermedias generadas un martes de abril de 2025, de una lista de revocación que se refresca sola y de un equipo aislado que lleva tres meses sin actualizaciones. Ninguno de esos tres elementos aparece en el informe trimestral de cumplimiento.
