Los programas de raíz de Google Chrome y Mozilla confirmaron el 20 de octubre que las claves privadas de ocho certificados intermedios emitidos por eMudhra (marca emSign) están comprometidas. Un certificado intermedio firma los certificados TLS que presentan los sitios web, por lo que quien posea una de esas claves podría emitir certificados válidos para cualquier dominio que un navegador aceptaría.
Qué se confirmó y cómo reaccionaron los navegadores
Un investigador reportó el hallazgo a los programas de raíz la noche del 17 de octubre. Chrome y Firefox bloquearon los ocho certificados en cuestión pocas horas después, tras la verificación inicial de Chrome. Apple y Microsoft también aplicaron bloqueos: Apple el 19 de octubre y Microsoft el 20 de octubre.
Chrome aplicó una actualización de CRLSet bloqueando los seis intermediarios utilizados para TLS el 17 de octubre por la tarde; Mozilla publicó una entrada OneCRL para Firefox que llegó a instalaciones con la configuración estándar ese mismo día por la noche. Estas listas de revocación se descargan automáticamente por los navegadores, por lo que no fue necesario reiniciar ni desplegar nuevas versiones del navegador para que el bloqueo surtiera efecto.
Alcance técnico del problema
De los ocho certificados comprometidos, seis eran intermediarios TLS que encadenan hasta emSign ECC Root CA – G3 (una raíz en los almacenes de confianza de Chrome y Apple, y hasta el 20 de octubre también en Mozilla). Además, cada uno de los ocho existe como una copia firmada de forma cruzada por Sectigo bajo su raíz AAA Certificate Services.
Chrome aplicó el bloqueo basado en la clave pública en lugar de en el certificado concreto, lo que también captura las copias cross-signed por Sectigo. Firefox y Chrome indicaron que revisaron otras entradas en sus almacenes y, por ahora, no encontraron otras instancias de este modo de fallo.
Impacto en aplicaciones y repositorios de certificados
No todos los programas verifican revocación de la misma forma. Herramientas y librerías que no consultan datos de revocación pueden seguir confiando en cadenas hasta que su código o su paquete de raíces se actualice. Por ello, varios proyectos y paquetes optaron por remover la raíz emSign ECC Root CA – G3 de sus bundles: certifi, webpki-roots y Homebrew (este último también eliminó la raíz de Sectigo y emSign Root TLS CA – G3).
Eliminar la raíz de un bundle tiene el efecto colateral de invalidar también certificados legítimos que encadenen a esa raíz, por lo que algunos servidores serán inaccesibles desde clientes que usen esos bundles hasta que migren a cadenas de certificado que encadenen a raíces distintas.
Qué se sabe (y qué no) sobre la causa
No se ha publicado información sobre cómo ni cuándo las claves privadas abandonaron eMudhra, ni si más partes además del investigador poseen las claves. eMudhra ha revocado los ocho certificados, y Mozilla, Google y otros programas de confianza trabajan con la CA y con tiendas de confianza para investigar la causa raíz.
Qué deben hacer los administradores y propietarios de sitios web
- Comprobar las cadenas de certificados instaladas en sus servidores y evitar dependencias en emSign ECC Root CA – G3 o en los intermediarios afectados. Si su certificado encadena a esas raíces, planifique emitir o solicitar un certificado que encadene a una raíz diferente y ampliamente confiable.
- Actualizar bibliotecas y paquetes que gestionen certificados (por ejemplo, actualizar a versiones que incluyan los bloqueos o cambios de bundle), y reconstruir binarios que incluyan verificadores estáticos si usan lenguajes o runtimes que requieren recompilación para aplicar la nueva política de bloqueo.
- Para administradores de sistemas: revisar cómo sus aplicaciones verifican revocación (OCSP/CRL) y, si dependen de bundles externos (certifi, webpki-roots, Homebrew, NSS, etc.), aplicar las actualizaciones publicadas por esos proyectos.
- Monitorizar CT (Certificate Transparency) y registros de certificados para detectar emisiones no autorizadas que pudieran haberse generado antes del bloqueo.
Nota: no existe, por ahora, un método público para detectar un posible uso pasado de las claves aparte de búsquedas en Certificate Transparency para certificados registrados.
Lee también:
- PHP anuncia parche crítico de seguridad programado para el 21 de octubre de 2026
- El dominio .PK de Pakistán ya está firmado con DNSSEC, pero solo un dominio valida
Fuente: The Hacker News
