Navegadores bloquean ocho certificados intermedios de eMudhra cuyas claves privadas eran números menores que 256

La seguridad de cada conexión HTTPS descansa en una cadena de confianza: el navegador acepta el certificado de un sitio porque lo firmó una autoridad intermedia, y acepta a esa intermedia porque la firmó una raíz incluida en su almacén de confianza. Quien obtenga la clave privada de una intermedia puede emitir certificados válidos para cualquier dominio y suplantar sitios si logra interceptar el tráfico. Eso es lo que ocurrió, al menos en potencia, con ocho certificados intermedios de eMudhra, una autoridad de certificación india cuyas raíces aceptan Mozilla, Google, Apple y Microsoft.

Según Google, el sábado 17 de octubre un investigador informó al programa de raíces de Chrome que las claves privadas de esas ocho intermedias se habían generado con aleatoriedad insuficiente, lo que permitía a cualquiera reconstruirlas a partir de los propios certificados. Para demostrarlo, el autor del reporte firmó un mismo mensaje con cada una de las ocho claves. El análisis preliminar de Mozilla en su registro de incidentes precisa la magnitud del fallo: las claves P-384, que deberían ser enteros aleatorios de unos 384 bits, eran todas números menores que 256, por lo que se pueden recuperar casi al instante. Seis de los certificados son para TLS y los otros dos, para firma de código. Chrome publicó ese mismo día una actualización de CRLSet que bloquea las claves afectadas sin necesidad de actualizar el navegador, y Android recibió una medida equivalente el lunes. Mozilla distribuyó el bloqueo mediante OneCRL a los usuarios de Firefox con configuración estándar en menos de tres horas, y el martes publicó Firefox 158.0.1 y las versiones ESR 115.43.1 y 153.5.1 para quienes no reciben esa lista, además de NSS 3.131.1, que elimina la raíz firmante del almacén usado por otras aplicaciones. De acuerdo con el sitio publicado por el autor del reporte, Apple bloqueó los certificados el 19 de octubre y Microsoft el 20.

Google añadió un dato que acota el riesgo: antes del bloqueo no había en los registros de Certificate Transparency ningún certificado emitido bajo esas intermedias, de modo que los clientes que exigen ese registro, como Chrome, no pudieron ser atacados con certificados fraudulentos. Aun así, tras saberse que varias personas habían recuperado las claves por su cuenta, Mozilla y Google decidieron retirar de forma urgente la raíz que firmó esas intermedias, emSign ECC Root CA - G3; en Chrome la retirada está prevista para el 27 de octubre. Los sitios con certificados legítimos que dependan de esa raíz deben reemplazarlos de inmediato, y Google indicó que evalúa si mantiene las demás raíces de eMudhra.

La certificadora asumió la responsabilidad en un comunicado. Explicó que las ocho intermedias se crearon en una ceremonia de generación de claves el 30 de abril de 2025 con módulos de seguridad de hardware certificados FIPS 140-2 nivel 3, y que un paso de envoltura y desenvoltura de claves produjo un segundo juego de claves débiles, que fue el que terminó publicado en los almacenes de confianza. El error pasó inadvertido durante unos 18 meses y dos ciclos de auditoría independiente. eMudhra afirma que siete de las intermedias nunca se usaron en producción y que la restante no había emitido ningún certificado. En su comunicado sostiene que la retirada de la raíz afecta al ecosistema de un único cliente en Estados Unidos, mientras que en el registro de Mozilla estimó en unos 30.000 los certificados que deberán migrar a su jerarquía RSA. La causa exacta todavía no está confirmada.

El problema no termina en los navegadores. Muchos programas no consultan listas de revocación ni exigen Certificate Transparency y dependen de paquetes de certificados incluidos en el sistema o en la propia aplicación. Por eso distribuciones de Linux y herramientas como Go, Node.js o certifi de Python publicaron actualizaciones de sus almacenes. Como análisis, el incidente muestra que la fortaleza de una clave no se puede dar por supuesta aunque se genere en hardware certificado y la ceremonia se audite, y que la rapidez de los navegadores contrasta con la lentitud del resto del software que confía en las mismas raíces. Para administradores, la tarea inmediata es actualizar los paquetes de certificados y revisar si algún servicio depende de la raíz retirada.