Skip to content

Se han comprometido ocho claves de CA de eMudhra. Esto es lo que significa para ti

Las claves de ocho CA intermedias de eMudhra podían recuperarse a partir de sus certificados públicos. Quién está afectado, qué hemos encontrado en Red Sift Certificates y qué hacer ahora.

Bhushan Lokhande·Principal Software Engineer
Published: October 21, 2026·8 min read

Ocho CA intermedias de eMudhra se crearon con claves privadas que cualquiera puede recuperar a partir del certificado público. Los navegadores las bloquearon pocas horas después del aviso del 17 de octubre, y los certificados ya están revocados. Hemos revisado todos los inventarios de Red Sift Certificates y Hardenize, y nos hemos puesto en contacto con las cuentas afectadas: las que tienen certificados bajo las ocho CA y las que tienen certificados bajo la emSign ECC Root CA - G3, que Firefox y Chrome están retirando. Si gestionas cualquier cosa que use TLS sin un navegador delante, actualiza tus almacenes de confianza.

Qué ha pasado

eMudhra, la CA india detrás de la marca emSign, creó ocho nuevas CA intermedias el 30 de abril de 2025: seis para certificados TLS y dos para firma de código. Un mes después, Sectigo firmó de forma cruzada las ocho bajo su raíz AAA Certificate Services, de modo que cada clave aparece en dos certificados que comparten el mismo Subject Key Identifier.

Nadie tuvo que robar estas claves. Cada una es una clave de curva elíptica P-384 cuyo valor secreto es inferior a 256, y en una de ellas es el número 4. Con el certificado en la mano, se puede recuperar la clave privada en un portátil en mucho menos de un segundo probando cada valor por turnos. eMudhra aún no ha confirmado la causa raíz. Según su explicación preliminar, un fallo en el script de la ceremonia de claves generó un segundo par de claves, débil, junto al par robusto, y el par débil se incluyó en las solicitudes de certificado porque las etiquetas se parecían.

Un investigador lo comunicó a los programas raíz de los navegadores el 17 de octubre de 2026, con un mensaje firmado por las ocho claves como prueba. Estas son las CA intermedias afectadas. Cada hash enlaza con su entrada en crt.sh.

CA intermedias de eMudhra afectadas

Cómo ha respondido el ecosistema

  • 17 de octubre. Un investigador comunicó las claves a los programas raíz de los navegadores. En pocas horas, Chrome y Firefox distribuyeron actualizaciones que indican a todos los navegadores instalados que las rechacen, sin necesidad de una nueva versión del navegador ni de reiniciar.
  • 18 y 19 de octubre. eMudhra y, después, Sectigo revocaron los certificados. Apple aplicó el mismo rechazo en iOS y macOS.
  • 20 de octubre. Windows se sumó. Mozilla publicó los detalles y retiró la emSign ECC Root CA - G3 de Firefox; Chrome ha anunciado que hará lo mismo. Mozilla mantiene la raíz RSA emSign Root CA - G1, que Chrome sigue revisando.

La buena noticia es que no se emitió nada bajo estas CA antes del bloqueo. Google confirmó que nunca se registró en Certificate Transparency ningún certificado encadenado a ellas, y eMudhra afirma que no emitieron ningún certificado de cliente.

Chrome, Safari, Firefox y Edge de escritorio rechazan un certificado TLS sin prueba de CT, así que ninguno de ellos podría haber confiado en una falsificación. Sin embargo, esa protección no es universal. Mozilla sigue trabajando en un problema con Firefox para Android 158.0.1, y los clientes que no exigen CT no obtienen ninguna protección. Desde la divulgación, los investigadores han registrado más de 100.000 certificados de demostración bajo estas claves, incluidas falsificaciones para google.com. Así de poco esfuerzo requiere.

Quién está afectado

  • Tienes un certificado de una de las ocho CA. La CA intermedia emisora está revocada, así que la cadena ya no es de confianza y los navegadores la rechazan. Sustitúyelo. eMudhra afirma que este grupo está vacío; comprueba tu inventario en lugar de fiarte de su palabra.
  • Tienes un certificado encadenado a la emSign ECC Root CA - G3. No está comprometido, pero Firefox ya no confía en esa raíz y Chrome dejará de hacerlo pronto. Según la estimación inicial de eMudhra, unos 30.000 certificados deben migrar a su raíz RSA, emSign Root CA - G1, que Mozilla mantiene. Vuelve a emitir el tuyo antes de que el cambio de Chrome llegue a tus usuarios.
  • Tu software se conecta a otros servidores mediante TLS. Es decir, todo el mundo. curl, Python, Node.js, Go, Java, los runners de CI, los clientes de API, el TLS mutuo y los dispositivos embebidos confían en un bundle de certificados en disco y, en su mayoría, no comprueban ni la revocación ni CT. Un investigador falsificó un certificado para una conocida API de pagos, y curl, Python y Node.js lo aceptaron con la configuración por defecto. Hasta que actualices tus bundles, los tuyos también lo aceptarán.
  • Verificas software firmado para Windows. Los certificados de firma de código no se registran en CT, así que nadie puede enumerar lo que se firmó bajo las dos CA de firma de código. eMudhra afirma que no se firmó nada, pero las claves son débiles desde el 30 de abril de 2025, así que una marca de tiempo no demuestra nada. Considera no fiable todo lo firmado bajo ellas.

Qué hemos encontrado en Red Sift Certificates y Hardenize

El 21 de octubre, buscamos en todos los inventarios de Red Sift Certificates y Hardenize certificados emitidos bajo las ocho claves, comparando el identificador de clave del emisor y los hashes de cadena de los dieciséis certificados. Encontramos un puñado, ninguno en un servicio en producción, todos registrados después de la divulgación por investigadores que probaban las claves recuperadas. También buscamos certificados bajo la raíz ECC G3. Nos hemos puesto en contacto con todas las cuentas de ambos grupos.

Puedes comprobarlo tú mismo. El widget Certificate Authorities de tu panel, que se muestra a continuación, enumera las CA detrás de tus certificados. Si aparece eMudhra, abre esos certificados, compara el SHA-256 de la CA emisora con la tabla anterior y fíjate en qué raíz termina la cadena. Solo están comprometidos los certificados bajo las ocho CA intermedias. Los certificados bajo la raíz ECC G3 no lo están, aunque habrá que volver a emitirlos. Los certificados de InCommon emitidos desde abril de 2026 también aparecen como eMudhra, porque sus CA intermedias se emiten bajo la raíz G1 de eMudhra; no requieren ninguna acción.

Certificate authorities widgetCertificate authorities widget
El widget Certificate Authorities en el panel de Red Sift Certificates

Qué debes hacer

  • Actualiza los almacenes de confianza en todas partes. Actualiza los paquetes de CA del sistema operativo, Python certifi, Node.js, Java cacerts, Homebrew y los almacenes de confianza incluidos en tus aplicaciones. Recompila los binarios de Go con una toolchain parcheada y los contenedores con imágenes base y dependencias actualizadas, y vuelve a desplegarlos.
  • Bloquea las CA comprometidas. Revisa mTLS, VPN, pasarelas de API y pines de certificados. Rechaza las claves afectadas tanto en las cadenas de eMudhra como en las firmadas de forma cruzada por Sectigo; eliminar una CA intermedia almacenada en caché no basta por sí solo.
  • Vuelve a emitir los certificados encadenados a la emSign ECC Root CA - G3. Sustitúyelos por certificados encadenados a una raíz de confianza antes de que el cambio de Chrome llegue a tus usuarios.
  • Mantén activada la verificación. Investiga los errores de certificado tras las actualizaciones en lugar de desactivar las comprobaciones.
  • Prueba la ruta real. Confirma que la aplicación real rechaza las cadenas comprometidas. Una prueba en el navegador o con curl en un portátil no demuestra que un servicio en producción esté protegido.
  • Identifica los dispositivos que no puedes actualizar. Restringe su acceso a la red. Cuando sea posible, usa una pasarela actualizada que termine TLS y valide los certificados upstream. Un cortafuegos por sí solo no basta.

Cómo puede ayudar Red Sift

Red Sift Certificates mantiene un inventario en tiempo real de todos los certificados de tu entorno, con la cadena que realmente envía cada servidor, de modo que un incidente de CA se convierte en una búsqueda y no en una carrera contrarreloj. El widget Certificate Authorities muestra de qué CA dependes, y la monitorización de Certificate Transparency te avisa cuando se emite un nuevo certificado para tus dominios y quién lo ha emitido.

Si todavía no eres cliente de Red Sift Certificates y quieres saber si algún certificado de tus dominios se encadena a estas CA, solicita una demo gratuita.

Fuentes

Bhushan Lokhande
Bhushan Lokhande
Principal Software Engineer

Bhushan is the leading Principal Engineer for Red Sift's Certificate products and innovation.