Crisis en HTTPS: Por qué Google, Mozilla y Apple bloquearon los certificados de eMudhra (CVE-2026-111943)
Un fallo crítico en la generación de llaves dejó expuestos ocho certificados intermedios de eMudhra, provocando su bloqueo en Chrome, Firefox, Safari y Windows y su salida del negocio SSL/TLS.
By Interscope Marketing Team
La seguridad del comercio electrónico y la navegación web depende de las Autoridades de Certificación (CA), entidades autorizadas por los navegadores para emitir los certificados SSL/TLS que activan el protocolo HTTPS. Esta semana, ese sistema de confianza vivió un episodio histórico: la autoridad certificadora india eMudhra anunció su salida definitiva del negocio global de certificados SSL/TLS tras descubrirse que las llaves privadas de ocho de sus certificados intermedios podían ser adivinadas casi al instante.
Una llave privada que podía deducirse en menos de un segundo
El incidente comenzó el sábado 17 de octubre de 2026, cuando un investigador independiente notificó a Mozilla y al programa de certificados raíz de Google Chrome que las llaves privadas asociadas a ocho certificados intermedios de eMudhra estaban comprometidas.
Según reportaron BleepingComputer y el equipo de respuesta a emergencias de la India (CERT-In), el problema se originó durante una ceremonia de generación de claves realizada en abril de 2025:
- Debido a un defecto en el proceso de empaquetado de claves (key wrap/unwrap) en los módulos de seguridad de hardware, se generó un conjunto de llaves privadas de curva elíptica P-384 con una aleatoriedad criptográfica extremadamente débil (con valores numéricos inferiores a 256; de hecho, The Register destacó que una de las llaves privadas equivalía literalmente al número 4).
- Esto permitía que cualquier persona con conocimientos técnicos pudiera calcular la llave privada a partir del certificado público en menos de un segundo.
¿Cuál era el riesgo real para los sitios web y usuarios?
Un certificado intermedio tiene la autoridad de firmar certificados para cualquier dominio en internet. Como explicó Cybersecurity Dive, quien posea la llave privada de una CA intermedia podría emitir certificados HTTPS falsos pero técnicamente válidos para suplantar sitios bancarios, tiendas en línea o portales corporativos mediante ataques de intermediario (Man-in-the-Middle), interceptando tráfico cifrado sin que el navegador mostrara advertencias.
Bloqueo global en navegadores, lenguajes y sistemas operativos
La respuesta de la industria fue inmediata:
- Navegadores y Sistemas Operativos: Como confirmó el Blog de Seguridad de Mozilla, tanto Firefox (mediante OneCRL) como Google Chrome (mediante CRLSet) bloquearon los certificados el mismo 17 de octubre. Apple y Microsoft aplicaron bloqueos equivalentes entre el 19 y el 22 de octubre. Además, Google anunció la eliminación completa del certificado raíz emSign ECC Root CA - G3 de la tienda de confianza de Chrome a partir del 27 de octubre.
- Entornos de desarrollo (Node.js y Go): El problema también obligó a actualizar entornos de programación que mantienen sus propios almacenes de certificados. Bajo el identificador CVE-2026-111943, Go lanzó las versiones 1.27.3 y 1.26.10, mientras que Node.js actualizó su lista de certificados raíz a NSS 3.131.1 en sus versiones del 21 de octubre (The Hacker News).
- Retiro del mercado: Aunque los registros de Transparencia de Certificados (CT) de Google confirmaron que no se llegaron a emitir certificados fraudulentos antes del bloqueo, la junta directiva de eMudhra anunció el 22 de octubre su retiro del negocio global de certificados SSL/TLS (The Hacker News).
Qué deben revisar los administradores web
Para las empresas y agencias digitales, este incidente deja dos tareas concretas:
- Verificar la cadena de certificados SSL/TLS: Si algún dominio o subdominio utilizaba certificados emitidos bajo la jerarquía de emSign ECC Root CA - G3, debe ser reemplazado de inmediato por una autoridad certificadora confiable (como Let's Encrypt, DigiCert o Cloudflare) para evitar errores de pantalla roja en Chrome y Firefox. Herramientas de inspección como el escáner SSLyze de HackerTarget permiten auditar la cadena de confianza TLS de cualquier servidor en segundos.
- Actualizar contenedores y servidores backend: Asegurarse de que los paquetes ca-certificates de Linux, así como los binarios de Node.js y Go en el servidor, estén actualizados para no confiar en cadenas revocadas durante llamadas a APIs externas.
Lectura relacionada: Seguridad de tu sitio web: 5 riesgos de las agencias sin control.
