El 17 de octubre de 2026, un investigador de seguridad conocido únicamente como "Wayne" envió un mensaje a los equipos de los programas de certificados raíz de navegadores de Apple, Google, Microsoft y Mozilla. El mensaje estaba firmado con las claves privadas de ocho autoridades de certificación (CA) intermedias operadas por eMudhra, el proveedor indio de confianza digital detrás de la marca emSign. El mensaje decía: 

"Tenemos un problema aquí – Wayne" 

Eso resultó ser una notable atenuación de la realidad. Las claves privadas no fueron robadas en una brecha de seguridad y la infraestructura de eMudhra nunca fue vulnerada. Las claves eran simplemente débiles: se generaron con tan poca aleatoriedad que cualquiera podía recalcularlas a partir de los certificados públicos en menos de un segundo. Una de las ocho claves, según un análisis independiente, era el número entero 4. 

Cinco días después, eMudhra anunció que saldría por completo del negocio global de certificados SSL/TLS. 

Para los CISO y arquitectos de seguridad —especialmente aquellos a cargo de entornos de tecnología operativa (OT), SCADA e IoT industrial— este incidente amerita mucha más atención de la que sugieren los titulares. Aquí está el panorama completo, incluidos los acontecimientos de las últimas 48 horas. 

Lo que realmente ocurrió: la versión corta 

Entre abril y mayo de 2025, eMudhra llevó a cabo una ceremonia de claves para generar 24 claves de CA subordinadas bajo su jerarquía emSign Root TLS CA – G3. Durante un paso de encapsulado/desencapsulado (wrap/unwrap) en el módulo de seguridad de hardware (HSM), una falla en el script de generación de claves creó un segundo conjunto de claves débiles de curva elíptica P-384. Debido a etiquetas de clave similares y a un error humano, ocho de esas claves débiles se utilizaron para certificados reales de CA intermedias. 

Las claves P-384 generadas correctamente se extraen de un rango de aproximadamente 10¹¹⁵ valores posibles. Estas claves tenían una entropía efectiva de 3 a 8 bits. Recuperarlas no fue un logro criptoanalítico: fue aritmética básica. 

Las ocho intermedias comprometidas: 

El detalle crítico que la mayoría de las coberturas pasa por alto: cada intermedia también existe como un segundo certificado con firma cruzada (cross-signed) por la raíz heredada "AAA Certificate Services" de Sectigo. Eliminar las raíces propias de eMudhra de su almacén de confianza (trust store) no es suficiente: cualquier sistema que aún confíe en la raíz de Sectigo aún puede validar las copias con firma cruzada. 

Línea de tiempo: 17 meses de exposición, 100 minutos para la mitigación 

Las claves débiles se crearon el 30 de abril de 2025 y fueron recuperables públicamente durante aproximadamente 17 meses antes de que alguien lo notara. Sin embargo, lo que ocurrió tras el descubrimiento fue una de las respuestas coordinadas más rápidas en la historia de la PKI: 

• 30 de abril de 2025 – Una ceremonia de claves defectuosa genera las ocho intermedias. 

• 14 de mayo de 2025 – Sectigo realiza la firma cruzada de las intermedias bajo AAA Certificate Services. 

• 23 de mayo de 2025 – Primera evidencia de firmas CRL no válidas procedentes de las mismas intermedias: una señal de alerta que fue mal diagnosticada en su momento. 

• 17 de octubre de 2026, 18:05 UTC – El Chrome Root Program recibe el reporte de Wayne. 

• 17 de octubre de 2026, 19:45 UTC – Chrome implementa una actualización de CRLSet que bloquea las claves comprometidas mediante hash SPKI. Firefox lo sigue a las 22:59 UTC. Tiempo total transcurrido: menos de dos horas. 

• 18 de octubre de 2026 – eMudhra revoca las ocho intermedias. 

• 19 de octubre de 2026 – Apple bloquea los certificados; Sectigo revoca sus copias con firma cruzada; las protecciones de Android se despliegan a través de Google Play Services. 

• 20 de octubre de 2026 – Microsoft bloquea los certificados; Mozilla retira por completo la confianza en emSign ECC Root CA – G3; Go, Firefox y Python lanzan versiones con parches aplicados. 

• 22 de octubre de 2026 – eMudhra anuncia que abandonará el negocio global de certificados SSL/TLS. El presidente V. Srinivasan confirmó que la revocación se llevó a cabo dentro de las 14 horas posteriores al hallazgo, que nunca se emitieron certificados de entidad final a partir de las intermedias afectadas y que no hubo filtración de datos. 

• 27 de octubre de 2026 – La eliminación de emSign ECC Root CA – G3 por parte de Chrome llega a todos los dispositivos. Los operadores de sitios web que todavía encadenen a esta raíz deben migrar a un nuevo certificado de inmediato o enfrentarán interrupciones en el servicio. 

¿Ha sido explotada? 

Al 27 de octubre de 2026, no se ha confirmado ningún uso malicioso. Google reporta que ningún certificado TLS encadenado a las intermedias afectadas fue registrado jamás en Certificate Transparency (CT), lo que descarta ataques contra clientes que obligan el uso de CT. 

Sin embargo, existen dos advertencias importantes para la planeación de riesgos: 

1. Las claves fueron recuperables durante 17 meses por cualquiera que se detuviera a buscarlas. No existe un registro técnico de quién lo hizo. 

2. Los certificados de firma de código no se registran en CT. En teoría, las dos claves de EM OV CS CA pudieron haber firmado binarios que parecerían provenir de un publicador verificado en sistemas Windows que omiten las verificaciones de revocación. No existe un registro público de qué firmaron, si es que llegaron a firmar algo. 

Trate las ocho claves como conocidas y en manos de atacantes. 

Por qué este incidente es distinto a DigiNotar y Symantec 

Las fallas de confianza en las CA no son nuevas: DigiNotar (2011) y Symantec (2017) terminaron de forma similar. No obstante, el incidente de eMudhra representa un modo de fallo diferente: 

• DigiNotar fue una intrusión: los atacantes robaron claves de una infraestructura comprometida. 

• Symantec fue una falla de gobernanza operativa: certificados emitidos de forma errónea que se descubrieron a través de los registros de CT. 

• eMudhra es una falla en la ceremonia de claves: la base criptográfica en sí misma estaba rota desde el momento de su generación, dentro del proceso que debería ser el más rigurosamente controlado que opera una CA. 

Esta distinción es importante porque las ceremonias de claves son el pilar de confianza para la PKI empresarial, la firma de código respaldada por HSM y, cada vez más, la identidad digital industrial. Si la ceremonia puede producir de manera silenciosa una clave con el valor "4", cualquier premisa derivada de ella se derrumba por completo. 

La parte de la que nadie habla: lo que esto significa para la PKI industrial y la OT 

Aquí es donde esta historia concierne de manera directa a las organizaciones que operan infraestructura crítica. 

1. Sus navegadores están parchados. Su parque de OT probablemente no. 

Los usuarios de Chrome y Firefox estuvieron protegidos en cuestión de horas. Ese modelo de protección, sin embargo, depende de la distribución automatizada de revocaciones (CRLSet, OneCRL, CRLite) a clientes que se actualizan continuamente. 

Ahora observe su entorno de OT: 

• Historiadores SCADA y estaciones HMI ejecutando versiones de Windows que no han recibido una actualización de almacén raíz en años 

• RTU, PLC y unidades terminales remotas con paquetes de CA preinstalados desde hace una década 

• Gateways VPN industriales y dispositivos de acceso remoto basados en redes celulares/RF que validan certificados con almacenes de confianza a nivel de firmware 

• Contenedores Docker, canalizaciones de compilación (build pipelines) y scripts de automatización basados en Python que descargan paquetes de certifi fijados hace meses 

• Dispositivos Linux embebidos en subestaciones y ductos que nunca reciben actualizaciones del almacén de confianza 

El aviso de seguridad de Fortinet señala explícitamente a los dispositivos embebidos e IoT, equipos heredados, máquinas virtuales y contenedores, así como a las utilerías que mantienen sus propios almacenes de confianza SSL (como Python), como las categorías de mayor riesgo. 

Red Hat ha confirmado que todas las versiones soportadas de RHEL —de la 6 a la 10— incluyeron la cadena comprometida en ca-certificates, y que cualquier conexión TLS basada en RHEL sigue siendo susceptible de confiar en certificados emitidos de forma fraudulenta hasta que el paquete se actualice. 

2. El riesgo de MITM en OT es estructural, no teórico. 

En IT, llevar a cabo un ataque de intermediario (man-in-the-middle) requiere situarse en la ruta de red. En OT, la ruta de red es a menudo la parte más favorable para el atacante: 

• Redes planas o deficientemente segmentadas en plantas heredadas 

• Túneles de acceso remoto de proveedores que terminan en jump hosts que confían en los almacenes de CA del sistema 

• Interfaces de gestión fuera de banda (out-of-band) en equipamiento antiguo 

• Gateways y convertidores de protocolos que terminan sesiones TLS y vuelven a cifrar hacia niveles superiores 

Un atacante con la clave de una CA intermedia comprometida y una posición ventajosa dentro de una red OT plana podría suplantar una estación de ingeniería ante un historiador, o un historiador ante una HMI, e interceptar o modificar el tráfico, incluyendo los comandos. Para entornos donde se utiliza TLS para proteger sesiones remotas de ingeniería, esta no es una preocupación abstracta. 

3. La firma de código impacta directamente en su cadena de suministro. 

Las dos intermedias de firma de código comprometidas (EM OV CS CA – G3B/G3C) se encadenan a emSign Root CS CA – G3, en la que confía Microsoft. eMudhra sostiene que ninguna de las dos CA entró a producción. Pero si su organización valida firmware firmado, utilerías firmadas de proveedores o parches firmados de SCADA en sistemas Windows con políticas de revocación obsoletas, este incidente es un recordatorio de que su decisión de confianza es tan buena como la CA más débil en su almacén raíz, y usted no controla qué CA eligen los proveedores. 

4. La advertencia de la CRL de 2025 es la lección real. 

En junio de 2025, Mozilla registró firmas de CRL no válidas procedentes de estas mismas seis intermedias TLS. eMudhra atribuyó esto a un proceso manual que hizo referencia a la clave equivocada, publicó CRL corregidas y el reporte se cerró. 

Esa era la misma causa raíz, visible con 16 meses de anticipación, pero mal diagnosticada. Para los líderes de seguridad en OT, la conclusión es contundente: monitoree la salud de las CA en sus propias dependencias de certificados de la misma forma en que monitorea los CVE en su propio software. Una CA que produce CRL no válidas es una CA cuya ceremonia de claves debe ser cuestionada. 

Lista de acciones para equipos de OT e infraestructura crítica 

Inmediato (esta semana): 

1. Haga un inventario de cada sistema en su entorno de OT que valide TLS o firmas: incluyendo appliances, gateways, HSM, imágenes de contenedor y dispositivos embebidos. Asuma que los navegadores están protegidos; todo lo demás es su responsabilidad. 

2. Actualice los almacenes de confianza más allá del nivel de sistema operativo: entornos de ejecución de lenguajes (certifi, crypto/x509 de Go —parchado en Go 1.26.10 y 1.27.3, registrado como CVE-2026-111943), almacenes de confianza de JVM, firmware de appliances y listas de CA específicas de proveedores. 

3. Verifique el riesgo de firma cruzada con Sectigo. Busque en los almacenes de confianza la raíz obsoleta "AAA Certificate Services"; los administradores de FortiOS, por ejemplo, deben ejecutar un grep en su lista de CA buscando "AAA" para detectar copias importadas manualmente. 

4. Compruebe la presencia de certificados emitidos por emSign en su infraestructura. La remoción por parte de Chrome de emSign ECC Root CA – G3 entra en vigor en su totalidad el 27 de octubre de 2026; cualquier elemento que aún dependa de esta cadena dejará de funcionar esta semana. 

A corto plazo (30 días): 

1. Audite el fijado de certificados (certificate pinning) y el comportamiento de revocación en aplicaciones OT. Los sistemas que omiten las comprobaciones de revocación o la validación de CT fueron —y siguen siendo— la población vulnerable. 

2. Revise el acceso remoto de proveedores. Asegúrese de que los jump hosts, los gateways VPN y los proxies de terminación TLS ejecuten paquetes de confianza actualizados y no listas de CA estáticas integradas en el firmware desde 2021. 

3. Bloquee ambas raíces de firma como medida de defensa en profundidad: emSign Root TLS CA – G3 y AAA Certificate Services de Sectigo (según las recomendaciones de Red Hat). 

Estratégico: 

1. Reduzca la dispersión de CA (CA sprawl). Cada raíz de confianza es una superficie de ataque que usted no controla. Consolide la emisión de certificados en CA con un rigor operativo comprobado y documente qué CA utilizan sus proveedores. 

2. Incorpore el monitoreo de CA a su programa de inteligencia contra amenazas. Las anomalías en CRL, firmas cruzadas imprevistas y discusiones en programas raíz (Common CA Database, mozilla.dev.security.policy) son indicadores tempranos. 

3. Evalúe rigurosamente sus ceremonias de claves. Si su organización opera una PKI interna —como lo hace la mayoría de los grandes operadores de OT para la identidad de dispositivos y acceso de ingeniería—, audite los scripts de ceremonias en HSM, el etiquetado de claves y los pasos de control dual. La falla de eMudhra fue un error de script sumado a un error humano y a una alerta temprana mal diagnosticada. Esa combinación existe en muchas organizaciones que gestionan PKI corporativas. 

Conclusión 

El incidente de eMudhra será recordado menos por su impacto —que, gracias a una respuesta de menos de dos horas por parte de Chrome y Mozilla, parece ser mínimo— y más por lo que dejó al descubierto. Una autoridad de certificación con más de 60 millones de certificados emitidos, respaldada por todos los programas de certificados raíz principales, generó claves de firma prácticamente sin entropía, las dejó expuestas durante 17 meses, pasó por alto sus propias alertas y colapsó en un plazo de cinco días tras la divulgación. 

Para los operadores industriales, la incómoda verdad es que la revocación a la velocidad de un navegador web no existe en OT. Su protección depende exclusivamente de que sus historiadores, gateways, dispositivos embebidos y vías de acceso remoto de proveedores hayan recibido almacenes de confianza actualizados; y en la mayoría de las plantas, nadie lo ha verificado. 

En ciberseguridad para OT, invertimos un enorme esfuerzo en el robustecimiento de endpoints y la segmentación de redes. Este incidente es un recordatorio de que la cadena de confianza que sostiene todo lo demás —los certificados, las CA y las ceremonias de claves— merece el mismo nivel de rigor. Porque cuando los cimientos son débiles, no importa qué tan fuertes sean los muros. 

Shieldworkz es una empresa especializada en ciberseguridad industrial OT integral que protege entornos SCADA, OT e IoT en infraestructuras críticas. Si no tiene certeza de si su infraestructura OT todavía confía en cadenas de certificados comprometidas —incluidas copias con firma cruzada ocultas detrás de raíces heredadas de Sectigo—, [hable con nuestro equipo] para una evaluación de postura de confianza en certificados y PKI.