Seguridad y privacidad

eMudhra abandona el negocio global de SSL tras descubrirse claves débiles

eMudhra se retirará del mercado global de SSL/TLS después de que investigadores descubrieran que ocho claves privadas de CA intermedias eran fácilmente adivinables, lo que obligó a un reemplazo masivo de certificados.

Racks de servidores bajo una cúpula de vidrio con luces de advertencia y cadenas rotas representando la confianza SSL rota
Ilustración creada para este artículo

Traducido automáticamente del original en inglés.

La autoridad de certificación india eMudhra anunció el jueves que abandonará su negocio global de certificados SSL/TLS. La decisión sigue al descubrimiento por parte de un investigador de seguridad de que ocho de sus claves privadas de Autoridad de Certificación (CA) intermedia eran críticamente débiles y fácilmente recuperables. Los principales proveedores de navegadores, incluidos Google y Mozilla, ya han tomado medidas para desconfiar de los certificados raíz afectados, impactando a decenas de miles de sitios web.

Qué sucedió

El incidente comenzó el 17 de octubre cuando un investigador informó a Apple, Google, Microsoft, Mozilla y eMudhra que ocho claves privadas de CA intermedia estaban comprometidas. Estas claves, que deberían haber sido números aleatorios grandes, eran todas inferiores al valor de 256. Esta extrema debilidad significaba que cualquiera podía calcular las claves privadas casi instantáneamente, rompiendo efectivamente el modelo de confianza criptográfica para cualquier certificado emitido bajo ellas. Seis de estas ocho claves se utilizaron para certificados TLS de sitios web.

En respuesta, Chrome y Firefox bloquearon los seis intermediarios TLS afectados dentro de las horas siguientes al informe. Google confirmó que ningún certificado de sitio web de estos intermediarios había aparecido en los registros públicos de Certificate Transparency antes del bloqueo, lo que significa que probablemente no se usaron para emitir certificados válidos a usuarios finales. eMudhra declaró que sus sistemas no fueron vulnerados y que nunca utilizó estas claves débiles específicas para emitir certificados a clientes. Sin embargo, el daño a la confianza fue inmediato y severo.

Tras la divulgación, la junta directiva de eMudhra decidió retirarse por completo del mercado global de SSL/TLS. La empresa citó que este segmento contribuye solo con aproximadamente el 1% de sus ingresos e implica complejos costos de soberanía de datos y cumplimiento normativo. También señaló que el escrutinio en redes sociales alrededor del incidente era desproporcionado al tamaño del negocio. eMudhra continuará operando sus otros servicios, incluidas las firmas digitales y la plataforma CertiNext, pero dejará de emitir nuevos certificados TLS globales.

Detalles clave

  • Chrome dejará de confiar en el certificado raíz emSign ECC Root CA - G3 la mañana del 27 de octubre, hora del Pacífico.
  • Mozilla decidió el 20 de octubre dejar de confiar en la misma raíz en Firefox, cortando el acceso a certificados legítimos encadenados a ella.
  • Aproximadamente 30.800 certificados sin expirar estaban encadenados a la raíz afectada al 21 de octubre, según el conteo de Chrome.
  • Alrededor del 99,9% de los certificados afectados fueron emitidos a través de InCommon, un servicio para la comunidad de educación superior.
  • eMudhra estimó que unos 30.000 certificados necesitan ser reemplazados, con el 97% emitido mediante el protocolo ACME.
  • Los clientes ACME estándar no reemplazan automáticamente los certificados fuera de su ventana de renovación a menos que soporten ACME Renewal Information (ARI).

Contexto

Para entender la gravedad, ayuda saber cómo funciona la confianza TLS. Los navegadores y sistemas operativos mantienen un "almacén raíz" de Autoridades de Certificación confiables. Cuando un sitio web presenta un certificado, el navegador verifica si se encadena hacia una de estas raíces confiables. Si la raíz es eliminada del almacén, como ocurrió con la raíz ECC de eMudhra, cada certificado emitido bajo ella se vuelve no confiable. Los usuarios verán advertencias de seguridad y los sistemas automatizados pueden fallar al conectar.

La falla específica aquí involucró claves privadas para CAs intermedias. Una CA intermedia se sitúa entre la raíz y el certificado de usuario final. Si la clave privada de una intermedia es conocida, un atacante puede emitir certificados fraudulentos para cualquier dominio. En este caso, las claves eran tan pequeñas (inferiores a 256) que no ofrecían ninguna seguridad. Aunque eMudhra afirma que estas claves no se usaron para emisión, la mera existencia de tales claves débiles en un entorno de producción señala una falla crítica en los procesos de generación de claves.

Por qué importa

Para equipos que ejecutan software autoalojado o gestionan servicios internos, este incidente destaca la fragilidad de depender de un único proveedor de certificados. Incluso si su sitio público usa una CA diferente, las herramientas internas o integraciones de socios podrían depender de certificados emitidos por eMudhra. Con Chrome y Firefox eliminando la confianza, cualquier servicio que dependa de estos certificados se romperá. Esto incluye APIs, microservicios e integraciones de terceros que validan estrictamente las cadenas TLS.

El proceso de transición también es complejo. Google ha instruido a los operadores a adquirir inmediatamente nuevos certificados de una jerarquía PKI diferente. Sin embargo, moverse desde una raíz basada en ECC a una basada en RSA, o a un proveedor completamente diferente, a menudo requiere intervención manual. Herramientas automatizadas como los clientes ACME pueden no manejar bien los reemplazos fuera de banda, especialmente si carecen de soporte para ACME Renewal Information. Esto crea una avalancha de trabajo manual para los equipos de IT y DevOps que deben rastrear cada endpoint afectado.

Además, el incidente plantea preguntas sobre transparencia e higiene operativa. eMudhra había publicado Listas de Revocación de Certificados (CRL) inválidas en 2025 para intermediarios similares, afirmando en ese momento que habían solucionado el problema regenerando las CRL con claves apropiadas. El reciente descubrimiento sugiere que esas correcciones pudieron haber implicado resellar con claves defectuosas, un detalle no divulgado en el informe anterior. Esta falta de claridad dificulta que los clientes evalúen el riesgo de permanecer con las raíces de eMudhra, como la raíz G1 RSA, que aún está bajo revisión por Chrome.

Qué puedes hacer

  • Audita tu inventario buscando cualquier certificado emitido por eMudhra, particularmente aquellos encadenados a emSign ECC Root CA - G3.
  • Verifica si tus servicios son parte de la federación InCommon, ya que el 99,9% de los certificados afectados pertenecen a este grupo.
  • Reemplaza inmediatamente los certificados afectados con otros de una jerarquía de CA diferente y confiable, como Let's Encrypt o un proveedor comercial.
  • Verifica que tus clientes ACME soporten ACME Renewal Information (ARI) para manejar futuras reemplazos forzados más suavemente.
  • Monitorea el estado de la raíz G1 RSA de eMudhra, ya que Chrome aún no ha decidido si mantenerla en el almacén raíz.
  • Actualiza los sistemas de monitoreo para alertar sobre cambios de certificados y problemas de confianza, asegurando que detectes raíces no confiables antes que los usuarios.

Más noticias

Todas las noticias