eMudhra revoca ocho CAs más tras un error de script que expuso claves RSA
eMudhra revocó ocho autoridades de certificación intermedias después de descubrir que su script de migración en Python exponía claves privadas RSA en la memoria, violando sus propias políticas de seguridad.
Traducido automáticamente del original en inglés.
La autoridad de certificación eMudhra ha revocado ocho autoridades de certificación (CA) intermedias adicionales después de determinar que un script personalizado en Python utilizado durante una ceremonia de claves expuso sus claves privadas RSA. La empresa declaró inicialmente que estas CAs no se veían afectadas por la vulnerabilidad de octubre, pero cambió de posición a principios de noviembre tras una investigación más profunda y discusiones con los programas de raíces de los navegadores.
Qué sucedió
El incidente se remonta a una ceremonia de claves el 30 de abril de 2025, donde eMudhra generó 16 claves CA en módulos de seguridad de hardware (HSM) Utimaco. Estas claves estaban destinadas a ser transferidas a HSM Crypto4A en las instalaciones de la empresa en EE. UU. y la UE. Dado que mover claves entre HSM de diferentes proveedores está restringido, el equipo de operaciones de PKI escribió un script en Python para envolver y desenvolver las claves para su transporte. Durante una prueba de este proceso de transferencia, el script leía las claves privadas desde el HSM hacia la memoria del ordenador de la ceremonia para reconstruirlas.
Para ocho claves ECDSA, una sola línea del script truncaba el valor privado a su byte principal, creando claves críticamente débiles que fueron posteriormente certificadas. Si bien esas ocho fueron revocadas en octubre, la empresa creía inicialmente que ocho claves RSA procesadas a través del mismo script eran seguras porque el script no las truncaba. Sin embargo, la investigación reveló que los componentes privados de estas claves RSA, como el exponente privado y los números primos, permanecían en la memoria del proceso de Python en el ordenador de la ceremonia.
Esta exposición significaba que eMudhra no podía demostrar el cumplimiento de su propia Declaración de Prácticas de Certificación (CPS) respecto al manejo de claves. La empresa afirmó que "no puede demostrar positivamente que este material clave estaba en cumplimiento" con las reglas que gobiernan cómo entran y salen las claves de los HSM. En consecuencia, las ocho CAs RSA fueron revocadas a finales de la semana pasada. Seis eran para certificados de sitios web TLS y dos para firma de código, cubriendo 195 certificados emitidos, incluidos 29 para los propios dominios de eMudhra.
Detalles clave
- Ocho CAs intermedias fueron revocadas debido a la exposición de claves RSA en la memoria, no al truncamiento de claves.
- La falla se originó en un script de Python utilizado durante una ceremonia de claves el 30 de abril de 2025.
- 195 certificados se vieron afectados, incluidos los de universidades, un condado y la propia eMudhra.
- La empresa alegó inicialmente que estas CAs no estaban afectadas en una actualización del 19 de octubre enviada a Mozilla.
- El motivo de la revocación se listó como cessationOfOperation (cese de operación) en lugar de keyCompromise (compromiso de clave).
- Microsoft eliminará las raíces restantes de eMudhra de Windows y Edge a partir del 16 de noviembre.
Antecedentes
Los Módulos de Seguridad de Hardware (HSM) son dispositivos físicos diseñados para generar y almacenar claves criptográficas de forma segura. Un principio fundamental del uso de HSM es que las claves privadas nunca deben salir del dispositivo en texto plano. Cuando las organizaciones necesitan migrar claves entre diferentes proveedores de HSM, suelen utilizar procesos de envoltura que cifran la clave para el transporte. En este caso, el script personalizado de eMudhra evitaba las salvaguardas estándar al leer la clave en la memoria del sistema para su reconstrucción, creando una ventana donde el material secreto era vulnerable a extracción o registro.
Las Autoridades de Certificación operan bajo auditorías estrictas como WebTrust y deben seguir una Declaración de Prácticas de Certificación (CPS). Si una CA no puede demostrar que una clave privada fue manejada según estas reglas, los navegadores y sistemas operativos pueden revocar la confianza en esa CA. Esto asegura que si una clave está potencialmente comprometida, incluso sin pruebas de mal uso, el riesgo se mitiga invalidando la cadena de confianza.
Por qué importa
Para los equipos que ejecutan software autoalojado, este incidente destaca la fragilidad de la confianza en el ecosistema público de certificados. Si depende de certificados de la marca emSign de eMudhra, sus servicios pronto podrían enfrentar errores de confianza en navegadores y sistemas operativos. Microsoft está eliminando las raíces restantes de eMudhra el 16 de noviembre, y Apple terminará la confianza en todos los certificados G1 el 30 de noviembre. Esto significa que las herramientas internas, APIs o aplicaciones orientadas al cliente que usen estos certificados dejarán de funcionar a menos que sean migrados.
Más allá de la interrupción inmediata, esta historia sirve como una advertencia sobre la creación de scripts personalizados en infraestructuras de seguridad críticas. Incluso grandes organizaciones auditadas pueden introducir vulnerabilidades severas mediante simples errores de codificación. Para líderes de DevOps y TI, subraya la importancia de verificar la procedencia y el manejo de materiales criptográficos, especialmente cuando se utilizan CAs de terceros que pueden estar saliendo del mercado o enfrentando problemas de estabilidad.
Qué puede hacer
- Compruebe si sus servicios usan certificados emitidos por las jerarquías G1 o G2C de eMudhra a través de registros de Transparencia de Certificados.
- Reemplace inmediatamente cualquier certificado afectado por uno de un proveedor estable y confiable.
- Actualice los sistemas macOS a las versiones 27.2.1, 26.7.3 o 15.8.3 para asegurar que herramientas integradas como curl rechacen las raíces comprometidas.
- Monitoree los registros de su aplicación para detectar fallos en el handshake TLS que puedan indicar problemas de confianza con certificados antiguos.
- Revise sus propios procedimientos de gestión de claves para garantizar que ningún script personalizado exponga claves privadas en la memoria.
- Verifique que su pila de monitoreo le alerte sobre cambios en el estado de vencimiento o revocación de certificados.



