El sábado 17 de octubre de 2026, a las 18:05 UTC, el Chrome Root Program recibió un reporte de un investigador de seguridad que se identifica solo como "Wayne": ocho certificados intermedios de una autoridad de certificación india, eMudhra (que opera bajo la marca emSign), tenían claves privadas generadas con una entropía criptográfica tan débil que cualquiera podría recuperarlas probando solo 256 valores posibles.
En lugar de simplemente reportar el problema a los proveedores, el investigador hizo lo que todos harían: firmó un mensaje de prueba con cada una de las ocho claves comprometidas y envió las pruebas directamente a los equipos de seguridad de Mozilla, Microsoft, Apple y Google. El resultado fue una respuesta durante el fin de semana que obligó actualizaciones de emergencia en toda la base de software del mundo.
Qué salió mal
eMudhra es una autoridad de certificación de confianza que emite certificados TLS para miles de sitios web, gobiernos y servicios financieros en la India y otros mercados emergentes. El problema se remonta a abril de 2025, cuando un script defectuoso generó un segundo conjunto de claves privadas P-384 significativamente más débiles. Por error, estas claves débiles fueron seleccionadas para firmas de certificados porque tenían etiquetas visualmente similares a las claves generadas correctamente.
El resultado fue catastrófico. Las ocho claves tenían valores menores que 2⁵⁶ — o sea, menores que 72 trillones — lo que, en términos prácticos, significa que cualquier persona con acceso a una computadora doméstica moderna puede probar todos los valores posibles en cuestión de minutos. El investigador Flüpke publicó en GitHub una de las claves comprometidas: el valor de la clave privada para el certificado "EM OV TLS CA – G3C" de eMudhra era simplemente el número 4.
Por qué los certificados intermedios son peores que los certificados de hoja
Perder una clave de certificado de hoja — el tipo que un sitio como google.com o tu banco usa — es un problema local. El administrador del dominio genera un nuevo par de claves, solicita un reemplazo y el certificado antiguo expira o es revocado. Es simple.
Un certificado intermedio es diferente. Los intermedios existen para mantener las claves raíz sin conexión y protegidas en módulos de seguridad de hardware (HSM). La raíz delega autoridad de firma al intermedio, que emite certificados al público. Un atacante que controla la clave privada de un intermedio hereda toda la confianza colocada en esa rama de la jerarquía. Puede acuñar certificados TLS válidos para cualquier dominio y saltarse las verificaciones de validación de dominio que las CAs legítimas aplican.
Además, estos certificados intermedios estaban "cross-signed" por la AAA Certificate Services de Sectigo — es decir, un cliente podía construir una cadena de confianza válida que pasaba por una raíz diferente. Si un navegador rechazaba solo la raíz de eMudhra, un atacante aún podía presentar una cadena que pasaba por Sectigo.
La respuesta de los navegadores
Mozilla reaccionó rápidamente. Recibió el reporte a las 20:06 UTC del 17 de octubre y empujó una actualización de lista de bloqueo a través del sistema OneCRL de Firefox en su infraestructura de Remote Settings para las 22:59 UTC. Esto obliga a Firefox a rechazar los certificados específicos independientemente de su validez criptográfica o fecha de expiración.
Google Chrome también bloqueó los seis intermedios comprometidos autorizados a emitir certificados ese día, a través de una actualización de CRLSet. Como esta actualización bloquea por SPKI (Subject Public Key Info), los usuarios de Chrome quedaron inmediatamente protegidos contra todos los certificados que compartían esas claves, sin necesidad de actualizar el navegador o reiniciar.
Apple añadió protecciones el 19 de octubre, y Android recibió una actualización equivalente a través de Google Play Services.
El problema oculto: la larga cola de software embebido
Aquí está la parte que nadie cuenta en las noticias: los navegadores pueden empujar listas de bloqueo de emergencia a cientos de millones de usuarios en horas. El resto de Internet es mucho más lento y fragmentado.
El 19 de octubre, el equipo de Go lanzó actualizaciones de seguridad de emergencia, en las versiones 1.27.3 y 1.26.10, con el CVE-2026-111943. A diferencia de un navegador web que depende de la tienda de certificados del sistema operativo anfitrión, la biblioteca estándar de Go `crypto/x509` implementa su propia lógica de verificación de certificados y empaqueta sus propios mecanismos de verificación de confianza.
Esto crea un trabajo real para las empresas. Si un microservicio backend fue compilado con una versión más antigua de Go, actualizar el toolchain en el host no hace absolutamente nada para el binario en ejecución, que ya contiene la lógica de verificación antigua. Asegurar el entorno significa encontrar cada binario Go compilado, actualizar el pipeline de build, recompilar contra el toolchain parcheado y desplegar en producción.
Un administrador puede parchear todas las estaciones de trabajo Windows y macOS y aún tener docenas de clientes de API internos, runners de pipelines de CI/CD y aplicaciones containerizadas que nunca vieron las actualizaciones del OneCRL de Mozilla o de Apple. En esos entornos, un handshake TLS exitoso solo muestra que el cliente aceptó el certificado bajo sus reglas de validación desactualizadas. No dice nada sobre si la conexión es segura.
Lo que eMudhra necesita demostrar ahora
Las Autoridades de Certificación se espera que mantengan separación de deberes, autorización multi-persona y módulos de seguridad de hardware fuertemente auditados. Ocho claves intermedias comprometidas al mismo tiempo apuntan a un fallo sistémico, no a un accidente aislado.
La empresa atribuyó el problema a un error de script, pero eso plantea preguntas que necesitan respuesta: ¿por qué el script generó claves tan débiles? ¿Por qué se seleccionaron claves débiles con etiquetas similares en lugar de las correctas? ¿Por qué la validación de entropía no bloqueó esta operación?
eMudhra ya revocó los ocho certificados comprometidos y suspendió la emisión de nuevos certificados bajo su raíz G3. La empresa se ha comprometido a trabajar con suscriptores impactados para migrar clientes fuera de la raíz afectada, emSign ECC Root CA - G3.
El sistema de confianza de toda la web depende de la premisa de que cada CA es impenetrable. Con ocho claves rotas por un script defectuoso, esa premisa parece más un deseo que una garantía — y deja una pregunta sin respuesta: ¿cuántas otras CAs en el mundo aún operan con fallos equivalentes, esperando que alguien las descubra?
Fuentes: BleepingComputer, Google Security Blog, The CyberSec Guru
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
