✨︎ Resumen (TL;DR):
- Google y Mozilla bloquearon ocho certificados intermedios de eMudhra: seis para TLS y dos para firma de software.
- Las claves privadas tenían entre 3 y 8 bits, aunque los certificados utilizaban la curva criptográfica P-384.
- Chrome y Firefox ya distribuyeron bloqueos, pero las aplicaciones con listas de confianza propias aún deben revisar sus dependencias. Google prevé retirar una raíz el 27 de octubre de 2026.
Google y Mozilla bloquearon ocho certificados intermedios de eMudhra después de detectar claves privadas de apenas 3 a 8 bits, una debilidad que permitía recuperarlas casi al instante. El expediente de Mozilla identifica seis certificados para TLS y dos para firma de software. Chrome, Firefox y Android ya recibieron medidas de protección, pero las aplicaciones que administran su propia lista de confianza todavía requieren cambios.
Qué falló en los certificados de eMudhra
Los ocho casos corresponden a certificados intermedios. Un certificado intermedio es un certificado que puede firmar otros certificados bajo una raíz que el dispositivo ya reconoce como confiable. Por eso, una clave privada débil en ese nivel puede facilitar la emisión de certificados falsos.
TLS es una tecnología que protege conexiones como HTTPS. Los certificados de firma de software ayudan a verificar la procedencia de un programa, por lo que los ocho certificados afectados no tenían exactamente el mismo uso.
Aunque utilizaban la curva criptográfica P-384, las claves privadas afectadas tenían tamaños de apenas 3 a 8 bits. Mozilla comprobó de forma independiente que sus valores eran inferiores a 256 y pudo recuperarlos con facilidad.
El riesgo consistía en emitir certificados falsos para sitios que el atacante no controlaba. Para leer o modificar el tráfico mediante esa suplantación, también tendría que interceptar la conexión y encontrar un programa que siguiera aceptando los certificados comprometidos.
eMudhra ubica el error en abril de 2025
eMudhra situó la generación defectuosa de las claves en el 30 de abril de 2025. En su comunicado del 21 de octubre de 2026, la empresa atribuyó el problema a una operación que produjo un segundo conjunto de claves débiles junto a las originales fuertes.
La compañía explicó que las claves débiles quedaron vinculadas a los certificados distribuidos y que continúa investigando la causa raíz. También negó una intrusión en su infraestructura y una filtración de datos.
eMudhra sostuvo que sus servicios de certificados de firma digital y eSign en India utilizan infraestructura separada y siguen operando normalmente.
Chrome y Firefox aplicaron bloqueos sin reinicios
Google informó que Chrome bloqueó las claves afectadas el 17 de octubre mediante una actualización de su lista de revocación. La medida no exigió instalar una nueva versión del navegador ni reiniciarlo.
Android recibió una protección equivalente a través de Google Play Services el 19 de octubre.
Firefox también distribuyó el bloqueo el 17 de octubre mediante OneCRL, su lista centralizada de certificados revocados. Mozilla señaló que la medida llegó a los usuarios con la configuración estándar sin actualizar ni reiniciar el navegador.
El 20 de octubre, Mozilla publicó versiones adicionales para quienes pudieran haber quedado fuera por sus ajustes personalizados. El 21 de octubre, lanzó Firefox 158.0.2 para Android, una versión que corrige un problema por el que algunos clientes no aplicaban de inmediato, al arrancar, los cambios de la lista de bloqueo incluida en la aplicación.
Google añadió que, antes de su bloqueo, ninguno de los certificados TLS de esas seis autoridades figuraba en los registros públicos de Certificate Transparency. Por ello, la empresa afirma que no pudieron utilizarse certificados fraudulentos de esas cadenas contra Chrome y otros clientes que exigen ese control.
Las aplicaciones todavía deben revisar su confianza
El bloqueo de un navegador no se traslada automáticamente a cada aplicación. Una app puede verificar certificados mediante el sistema operativo, una biblioteca o una lista propia.
Cloudflare advirtió que actualizar un SDK, el conjunto de herramientas que usa un desarrollador, puede dejar intacta la política de confianza subyacente. Su guía pide:
- Revisar las dependencias.
- Reconstruir las imágenes de contenedores afectadas.
- Aplicar los reinicios o despliegues necesarios.
Cloudflare también desaconseja resolver los errores de certificados desactivando su verificación. Hacerlo elimina la protección de autenticación que las actualizaciones buscan restablecer. La empresa informó que su revisión no había identificado explotación activa en sus servicios.
Google prepara el retiro de una raíz
Para los programas que usan el almacén de confianza de Google, pero no reciben las listas de bloqueo de Chrome, Google adoptó otra medida: retirar la raíz emSign ECC Root CA – G3. La compañía prevé distribuir ese cambio el 27 de octubre de 2026, con llegada anticipada a los canales de prueba.
El retiro también dejará sin confianza a certificados legítimos que dependan de esa raíz. Google pide a los administradores de los sitios afectados obtener e instalar un certificado de otra jerarquía aceptada antes de que el cambio provoque interrupciones.
El bloqueo de Chrome y Firefox no actualiza automáticamente cada biblioteca o lista propia. Las aplicaciones deben revisar dependencias y despliegues, mientras que los administradores de sitios que dependan de emSign ECC Root CA – G3 necesitan instalar un certificado de otra jerarquía aceptada antes del 27 de octubre de 2026.
