Incidente de eMudhra: ocho claves de CA eran triviales de adivinar; qué deben comprobar ahora los titulares de certificados TLS

6 de noviembre de 2026  |  Certificados  |  Seguridad informática

En octubre de 2026 se supo que la autoridad de certificación india eMudhra había emitido ocho certificados intermedios (CA intermedias) con claves privadas prácticamente inútiles. Las claves privadas eran números enteros inferiores a 256; una de ellas era, literalmente, el número 4. Quien conozca una clave de este tipo puede firmar certificados para cualquier dominio en nombre de la autoridad de certificación. Por ello, los fabricantes de navegadores reaccionaron en cuestión de horas: bloquearon los certificados intermedios y retiraron la CA raíz asociada, emSign ECC Root CA – G3, de sus listas de confianza.

Este artículo explica qué ocurrió exactamente, por qué una clave «4» supone un fallo catastrófico, quiénes están afectados —y quiénes no— y qué deben revisar ahora los administradores de sitios web, servidores de correo y cortafuegos. Nos ceñimos estrictamente a lo que acreditan las fuentes primarias. En las primeras noticias y en las redes sociales también circulan versiones que no se ajustan a los hechos. Lo veremos a continuación.

Resumen: qué es cierto y qué no

Cronología

• 17 de octubre de 2026: se notifica el incidente a Mozilla (recibido a las 18:05 UTC según Bugzilla). A las 22:59 UTC ya se ha distribuido el bloqueo de los certificados intermedios a través de OneCRL de Mozilla, es decir, en menos de tres horas desde la recepción del aviso en Mozilla.
• 18 de octubre de 2026: eMudhra revoca los ocho certificados intermedios.
• 19 de octubre de 2026: Sectigo revoca los certificados cruzados con los que había firmado las ocho CA intermedias.
• 20 de octubre de 2026: Mozilla publica Firefox 158.0.1, ESR 115.43.1 y ESR 153.5.1, así como NSS 3.131.1. Con estas versiones se retira la raíz emSign ECC Root CA – G3. Además, entre el 20 y el 21 de octubre aparecen en los registros de transparencia de certificados 107.107 certificados firmados con seis de las ocho claves débiles (véase más abajo).
• 22 de octubre de 2026: eMudhra anuncia que abandonará el negocio de los certificados TLS públicos. La firma de código y S/MIME seguirán funcionando bajo sus propias raíces.
• 27 de octubre de 2026: Chrome también retira la CA raíz.
• 16 y 30 de noviembre de 2026: fechas límite para los certificados G1 antiguos (Chrome/Mozilla y Apple, respectivamente), relevantes, según eMudhra, para la transición del grupo de clientes estadounidenses afectado.

Por qué una clave privada «4» supone un fallo catastrófico

Una autoridad de certificación (CA) confirma mediante su firma digital que un certificado pertenece a un dominio. Los navegadores confían en esa firma mientras la CA figure en su lista de confianza. La seguridad se basa en que solo la CA conoce la clave privada.

En los certificados de curva elíptica (ECDSA), la clave privada es un número muy grande d. La clave pública es un punto Q = d · G de la curva (G es el punto base establecido). Obtener el número d a partir de Q es prácticamente imposible si se trata de un número aleatorio de 384 bits. Pero si d es pequeño, por ejemplo 4, basta con calcular sucesivamente 1·G, 2·G, 3·G, 4·G … y comparar los resultados con el punto público. Esto lleva segundos y no requiere ningún conocimiento especializado.

La clave pública figura en cada certificado, por lo que cualquiera puede consultarla. Así, cualquiera que realice estos cálculos puede generar certificados aparentemente válidos en nombre de la CA para cualquier dominio, mientras el navegador siga confiando en ella. Precisamente por eso Mozilla y otros los bloquearon de inmediato.

Descargamos los ocho certificados intermedios citados en Bugzilla de los registros públicos de transparencia (crt.sh), utilizando sus huellas SHA-256, y comparamos, para cada uno, k · G con el punto público para valores de k de 1 a 1000. Los ocho certificados tienen una clave P-384 y en los ocho encontramos una coincidencia:

Los valores coinciden con los datos de Bugzilla y con la información publicada en los medios (entre ellos, The Register: una de las claves era «literalmente 4»). Con estos valores no hemos firmado ni emitido nada; el cálculo se limita a comprobar certificados públicos.

La causa según eMudhra

Según la explicación de eMudhra en Bugzilla, las claves débiles se generaron durante una ceremonia de claves celebrada el 30 de abril de 2025. En ella se realizó una prueba de encapsulado y desencapsulado de claves (Wrap/Unwrap) como parte de una desviación autorizada del procedimiento habitual. Un error en el código habría provocado que se generara en el dispositivo un segundo par de claves débiles. Este par se habría utilizado por error para crear la solicitud de certificado porque los nombres de las claves eran similares. A continuación, se emitieron los certificados, se incorporaron a las listas de confianza y permanecieron en ellas durante más de un año, hasta que el fallo salió a la luz.

Según The Register, el investigador de seguridad Scott Helme descubrió la clave «4». Las fuentes primarias que hemos consultado no describen el método con el que se detectó el fallo; no obstante, cualquiera puede comprobar si las claves tienen valores pequeños a partir de los certificados públicos.

¿Quiénes están afectados y quiénes no?

La cadena consta de tres niveles: la CA raíz, la CA intermedia y el certificado final del sitio web o del servidor. El nivel afectado era el intermedio. De ello se desprende lo siguiente:

• Las claves de los titulares de los certificados (la clave de su servidor) no están afectadas, según todas las fuentes de las que disponemos. No es necesario sustituirlas por el supuesto de que sean «conocidas».
• Zertifikate, die unter der entfernten Root laufen, werden von Browsern nicht mehr akzeptiert. Sie müssen ersetzt werden, weil die Vertrauenskette weg ist, nicht weil der Server-Schlüssel schwach ist. Laut der Analyse des Chrome-Root-Programms (Stand 21.10.2026) betrifft das rund 30.800 noch gültige Zertifikate. 30.791 davon wurden von Unter-CAs von Internet2/InCommon ausgestellt, einem US-Verbund, der vor allem Hochschulen und Forschungseinrichtungen bedient. eMudhra spricht von einem einzigen Kundenverbund in den USA.
• Los demás clientes de eMudhra no están afectados, según la empresa. Las firmas digitales, eSign, emSigner, CertiNext, SecurePass, PrivaTrust y emCA siguen funcionando en una infraestructura independiente.

Por tanto, para los clientes de Alemania, Austria y Suiza, la probabilidad de utilizar un certificado que dependa de esta raíz es baja. Solo podrá saberlo con certeza si lo comprueba. Se hace en pocos minutos; consulte la lista de comprobación.

Los 107.107 certificados en los registros de transparencia

Según Bugzilla, tras la revocación aparecieron en los registros de Certificate Transparency, entre el 20 y el 21 de octubre de 2026, 107.107 certificados firmados con seis de las ocho claves débiles. Entre ellos hay certificados de prueba de concepto confirmados, por ejemplo, con google.com como nombre. La mayoría dependen de los certificados cruzados de Sectigo, que ya han sido revocados.

Esto demuestra dos cosas: en primer lugar, cualquiera con conocimientos básicos de criptografía podía explotar el fallo de inmediato; en segundo lugar, pone de manifiesto el valor de los registros de transparencia, que permiten que cualquiera vea estas emisiones. Las fuentes de las que disponemos no permiten determinar si alguno de estos certificados se utilizó de forma maliciosa fuera de las pruebas, y no afirmamos que así fuera.

Qué medidas han tomado los fabricantes de navegadores y las CA

Según sus propias declaraciones en el debate de dev-security-policy, Mozilla no considera que haya otras autoridades de certificación afectadas.

Lista de comprobación: qué debe revisar ahora

1. Identifique al emisor de sus certificados. En cualquier equipo con OpenSSL:

   openssl s_client -connect ihre-domain.example:443 -servername ihre-domain.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

   Si el emisor es eMudhra o emSign (por ejemplo, «EM DV TLS CA – G3B» o «G3C»), utilice -showcerts para comprobar toda la cadena y la raíz. Si depende de emSign ECC Root CA – G3, es necesario sustituir el certificado.
2. Revise todos los servicios, no solo el sitio web. Servidores de correo (SMTPS, IMAPS), pasarelas VPN, interfaces de cortafuegos, balanceadores de carga, servicios internos, dispositivos y appliances con certificados propios.
3. Consulte los certificados públicos de su dominio. A través de crt.sh (buscando %.ihre-domain.example) puede ver todos los certificados emitidos para su dominio, incluidos aquellos que desconoce. Es una buena oportunidad para detectar emisiones no deseadas.
4. Sustituya los certificados afectados. Recurra a otra CA consolidada o utilice ACME (por ejemplo, Let’s Encrypt). Aproveche la sustitución para generar también una nueva clave del servidor. Este incidente no obliga a hacerlo, pero es una buena práctica al cambiar de CA.
5. Trust-Stores eigener Geräte prüfen. Wer die eMudhra-Root in eigenen Geräten, Java-Keystores, Containern oder Zertifikats-Bundles fest eingetragen hat, sollte sie dort entfernen. Browser aktualisieren das selbst, solche Bestände nicht.
6. Actualice Firefox. Los bloqueos están incluidos a partir de la versión 158.0.1 y de las versiones ESR 115.43.1 / 153.5.1. En los equipos gestionados, compruebe que se reciben las actualizaciones.
7. Automatice. Si gestiona los certificados manualmente, debería pasar a la renovación automática (ACME). Así, cambiar de CA será un cambio de configuración y no una intervención de emergencia.

Qué podemos aprender de este incidente

• Elegir una CA es una decisión de gestión del riesgo. Lo decisivo es la transparencia, la calidad de los procesos y la participación en los programas de certificados raíz. El precio no dice nada al respecto. El incidente revela un fallo de procedimiento durante una ceremonia de claves que podría producirse en cualquier CA.
• Certificate Transparency funciona. Los registros de acceso público permitieron delimitar rápidamente el alcance del incidente e identificar los 107.107 certificados.
• La agilidad criptográfica merece la pena. Quien renueva los certificados automáticamente y puede cambiar de CA sin tener que intervenir manualmente en decenas de sistemas puede resolver incidentes de este tipo en un día de trabajo en lugar de una semana.
• Supervise sus dominios. La supervisión de los registros de transparencia (por ejemplo, mediante crt.sh o servicios con notificaciones por correo electrónico) permite detectar cuándo alguien emite certificados para su dominio.
• Varias capas de protección. Los certificados TLS son solo una capa. También ayudan los registros CAA en el DNS (que establecen qué CA puede emitir certificados para su dominio) y la autenticación de dos factores. Encontrará más información en nuestro artículo Cómo proteger Odoo 19: cortafuegos, 2FA & Web RBL.

Preguntas frecuentes

¿Qué ocurrió exactamente en eMudhra?

Acht Zwischenzertifikate der Zertifizierungsstelle eMudhra hatten private Schlüssel, die ganze Zahlen kleiner als 256 waren (einer: die Zahl 4). Dadurch konnte jeder aus dem öffentlichen Zertifikat den privaten Schlüssel berechnen und gültig aussehende Zertifikate unterschreiben. Die Zwischen-CAs wurden widerrufen, die Root emSign ECC Root CA – G3 wurde aus Firefox (20.10.2026) und Chrome (27.10.2026) entfernt.

¿Entregó eMudhra la clave privada «4» a sus clientes?

No. Las claves débiles pertenecían a los certificados intermedios de la propia CA. No eran claves de clientes ni se entregaron a clientes. Que en las redes sociales se afirmara lo contrario no cambia este hecho.

Como cliente de eMudhra, ¿debo sustituir mi certificado de inmediato?

Solo si su certificado TLS depende de la raíz emSign ECC Root CA – G3. Según eMudhra, esto afecta a un único consorcio de clientes estadounidense con unos 30.800 certificados. Para el resto de los clientes, eMudhra indica que no es necesario tomar ninguna medida. Compruebe el emisor de su certificado antes de actuar.

¿Cómo puedo saber si mi certificado está afectado?

Por el emisor y la cadena: consulte el certificado en el navegador o utilice el comando de OpenSSL de la lista de comprobación. Nombres como «EM DV TLS CA – G3B», «EM OV TLS CA – G3C» o «emSign ECC Root CA – G3» apuntan a la cadena afectada.

¿Debo sustituir la clave privada de mi servidor?

No a causa de este incidente. Según las fuentes, la clave del servidor no está afectada. Aun así, si es necesario sustituir el certificado, se recomienda generar una clave nueva.

¿Pueden los atacantes generar certificados falsos para mi dominio?

Con las ocho claves era técnicamente posible firmar certificados para cualquier dominio. Esto solo surtía efecto mientras los navegadores confiaran en la cadena. Tras los bloqueos de Mozilla y Chrome, ya no es posible en los navegadores actualizados. En los dispositivos que no se actualizan o que tienen la raíz añadida de forma fija, el riesgo puede persistir durante más tiempo. Por eso, supervise los certificados de su dominio.

¿Están afectados los certificados de Let’s Encrypt o de otras CA?

Según las fuentes publicadas, no. Mozilla no considera que haya otras CA afectadas.

¿Qué significa que eMudhra abandone el negocio de TLS?

eMudhra deja de emitir nuevos certificados TLS públicos. La firma de código, S/MIME, las firmas digitales y eSign siguen funcionando. Quienes obtenían sus certificados TLS de eMudhra necesitan un nuevo proveedor.

¿Está afectado Odoo?

Odoo en sí no está afectado. Pero, como en cualquier aplicación web, el certificado TLS de su dominio de Odoo debe proceder de una CA de confianza. Compruebe el emisor, especialmente si los certificados no se renuevan automáticamente.

Fuentes

Consultado el 6 de noviembre de 2026:

• Mozilla Bugzilla, incidencia 2083449 (informe del incidente, cronología y huellas digitales de los certificados): bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Mozilla Security Blog, 20.10.2026: Protección de los usuarios de Firefox tras el compromiso de los certificados intermedios de eMudhra
• eMudhra, comunicado: emudhra.com/en/post/certificate-security-incident
• The Register, 20.10.2026: Comprometidas las claves privadas de la autoridad de certificación india eMudhra: una de ellas era el número 4
• Mozilla dev-security-policy: Hilo de debate sobre el incidente
• Búsqueda en Certificate Transparency: crt.sh

La determinación de los ocho valores de las claves procede de nuestros propios cálculos a partir de certificados públicos. Las afirmaciones sobre la causa, la no emisión de certificados finales y el número de clientes afectados proceden de eMudhra o de Bugzilla y no las hemos verificado de forma independiente.

Asistencia de Biricon IT Services

Si no tiene claro quién ha emitido sus certificados TLS, estaremos encantados de ayudarle: a elaborar un inventario de todos los certificados de servidores web, servidores de correo, cortafuegos y appliances, a cambiar a otra CA, a implantar la renovación automática (ACME) y a supervisar sus dominios. Como proveedores de servicios informáticos, gestionamos servidores, cortafuegos y aplicaciones web para pequeñas y medianas empresas.

Contactar ahora

Información actualizada a 6 de noviembre de 2026. La situación puede cambiar; las publicaciones de Mozilla, Google, Apple y eMudhra son las fuentes de referencia.