Las claves privadas de ocho certificados intermedios de eMudhra resultaron tan débiles que podían recuperarse casi al instante. Google y Mozilla desplegaron bloqueos para impedir su uso en la suplantación de sitios web, pero la protección debe llegar también a aplicaciones y sistemas que administran sus propias listas de confianza.
El expediente de Mozilla precisa que seis certificados eran para TLS y dos para firma de software. TLS protege conexiones como HTTPS; los certificados de firma de software ayudan a verificar la procedencia de un programa. Las autoridades intermedias pueden firmar otros certificados bajo una raíz que el dispositivo reconoce como confiable.
Claves de 3 a 8 bits en certificados P-384
Aunque utilizaban la curva criptográfica P-384, las claves privadas afectadas tenían tamaños de apenas 3 a 8 bits, según Ars Technica. Mozilla comprobó de forma independiente que sus valores eran inferiores a 256 y pudo recuperarlas con facilidad.
El riesgo consiste en emitir certificados falsos para sitios que el atacante no controla. 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, explica Mozilla.
eMudhra situó la generación defectuosa de las claves el 30 de abril de 2025. En su comunicado del 21 de octubre de 2026, la empresa atribuye el problema a una operación que produjo un segundo conjunto de claves débiles junto a las originales fuertes. Afirma que las débiles quedaron vinculadas a los certificados distribuidos y que continúa investigando la causa raíz.
La compañía negó una intrusión en su infraestructura y una filtración de datos. También sostuvo que sus servicios de certificados de firma digital y eSign en India funcionan con infraestructura separada y siguen operando normalmente.
Chrome y Firefox distribuyeron bloqueos automáticos
Google informó que Chrome bloqueó las claves afectadas el 17 de octubre mediante una actualización de su lista de revocación, sin exigir una nueva versión del navegador ni un reinicio. 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ñala que llegó a los usuarios con configuración estándar sin actualizar ni reiniciar el navegador. El 20 de octubre publicó versiones adicionales para quienes pudieran haber quedado fuera por sus ajustes personalizados.
El 21 de octubre, Mozilla lanzó Firefox 158.0.2 para Android. Esa versión corrige un problema por el que algunos clientes no aplicaban inmediatamente, al arrancar, los cambios de la lista de bloqueo incluida en la aplicación.
Google añadió que, antes de su bloqueo, ningún certificado TLS de esas seis autoridades figuraba en los registros públicos de Certificate Transparency. Por ello, afirma que no pudieron utilizarse certificados fraudulentos de esas cadenas contra Chrome y otros clientes que exigen ese control.
Las aplicaciones y los sitios tienen tareas pendientes
Una aplicación puede verificar certificados mediante el sistema operativo, una biblioteca o una lista propia. Cloudflare advierte 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 dependencias, reconstruir las imágenes de contenedores afectadas y 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 adoptó otra medida para programas que usan su almacén de confianza pero no reciben las listas de bloqueo de Chrome: retirar la raíz emSign ECC Root CA - G3. Prevé distribuir ese cambio el 27 de octubre de 2026, con llegada anticipada a 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.
