Detectado un fallo criptográfico que compromete a confianza nos certificados dixitais

Mozilla e Google confirmaron o compromiso das claves privadas asociadas a oito certificados de autoridades de certificación intermedias de eMudhra, unha entidade emisora de certificados dixitais integrada na infraestrutura pública de confianza de Internet.

O incidente foi comunicado o 17 de outubro de 2026 por un investigador de seguridade que demostrou que as claves privadas podían recuperarse debido a un procedemento defectuoso de xeración criptográfica. Posteriormente, os equipos de seguridade de Mozilla e Google verificaron os achados e adoptaron medidas para impedir que os certificados afectados continuasen sendo considerados fiables.

A gravidade do incidente reside en que unha autoridade de certificación intermedia dispón da capacidade de asinar certificados dixitais que poden ser recoñecidos como lexítimos polos navegadores e outros sistemas. Se un atacante obtén a súa clave privada, podería xerar certificados fraudulentos para dominios que non controla e utilizalos para suplantar servizos lexítimos ante clientes que continúen confiando nesa autoridade.

A posibilidade de emitir estes certificados non implica por si mesma que se producisen ataques efectivos. Ata o momento, as fontes oficiais consultadas non acreditaron ningunha campaña de explotación que utilizase as claves comprometidas.

Que ocorreu e cal é a orixe do problema
A investigación publicada no sistema de seguimento de incidencias de Mozilla identifica un defecto no procedemento de xeración de claves realizado por eMudhra o 30 de abril de 2025.

As oito claves afectadas utilizaban criptografía de curva elíptica P-384, un algoritmo que, cando se implementa correctamente, ofrece un nivel de seguridade elevado. Porén, o problema non se atopaba no algoritmo, senón na selección dos valores empregados como claves privadas.

En lugar de xerarse a partir de números aleatorios suficientemente grandes, as claves privadas afectadas tiñan valores inferiores a 256.

Esta circunstancia reduciu drasticamente o espazo de busca necesario para recuperalas. Os investigadores comprobaron que podían reconstruírse practicamente de maneira inmediata a partir das correspondentes claves públicas.

Mozilla conseguiu recuperar as claves de maneira independente, confirmando que o problema era reproducible e que non dependía de información secreta obtida mediante unha intrusión nos sistemas de eMudhra.

Este feito resulta especialmente significativo porque demostra que o uso de algoritmos criptográficos robustos non garante a seguridade cando existen deficiencias nos procedementos de xeración e xestión de claves.

Como pode afectar ás conexións HTTPS
A seguridade dunha conexión HTTPS depende de distintos mecanismos, entre eles a validación do certificado dixital presentado polo servidor.

Nunha infraestrutura de clave pública ou PKI, os certificados dos sitios web valídanse mediante unha cadea de confianza que conecta o certificado do servidor cunha autoridade de certificación raíz recoñecida polo sistema.

As autoridades de certificación intermedias participan nesta cadea e poden emitir certificados dentro dos límites das súas autorizacións.

Cando a clave privada dunha autoridade intermedia queda comprometida, un atacante podería utilizala para asinar certificados fraudulentos.

Se o sistema cliente continúa confiando nesa autoridade e acepta a cadea presentada, o certificado podería utilizarse para suplantar a identidade dun servizo lexítimo.

Nun escenario no que o atacante tamén puidese interceptar ou redirixir as comunicacións, isto podería facilitar ataques de intermediario ou Man-in-the-Middle, con posibles consecuencias para a confidencialidade e a integridade do tráfico.

Non obstante, a explotación efectiva require condicións adicionais. O compromiso destas claves non permite interceptar automaticamente todas as conexións HTTPS nin implica que os mecanismos de cifrado TLS fosen vulnerados.

O risco depende da cadea de certificación, das restricións aplicables ao certificado, dos mecanismos de validación empregados polo cliente e das medidas de revogación ou retirada de confianza que se implementasen.

Oito certificados comprometidos con distintos usos
A investigación identifica oito certificados intermedios afectados, dos cales seis estaban destinados á emisión de certificados TLS e dous á sinatura de código.

Esta distinción é relevante porque non todos os certificados comprometidos teñen as mesmas capacidades nin poden utilizarse indistintamente para suplantar sitios web.

Google confirmou que os seis certificados intermedios relacionados con TLS foron bloqueados mediante as súas claves públicas. Os dous certificados destinados á sinatura de código non requirían o mesmo bloqueo no proceso de validación HTTPS de Chrome debido ás restricións de uso dos seus certificados.

eMudhra comunicou que ningunha das autoridades intermedias afectadas emitira certificados finais lexítimos, aínda que unha delas chegou a despregarse en produción.

A compañía tamén indica que o incidente non afecta ás claves privadas das súas autoridades raíz nin, segundo a investigación realizada ata o momento, ás restantes autoridades intermedias.

Polo tanto, o incidente debe limitarse aos certificados e ás claves identificados, sen estender automaticamente o compromiso ao conxunto dos servizos de certificación de eMudhra.

Mozilla e Google implementaron medidas de protección
Mozilla e Google confirmaron o compromiso das claves privadas asociadas a oito certificados de autoridades de certificación intermedias de eMudhra, unha entidade emisora de certificados dixitais integrada na infraestrutura pública de confianza de Internet.

Tras recibir a notificación, Mozilla e Google iniciaron procedementos de resposta destinados a retirar a confianza nos certificados afectados.

Mozilla
Mozilla utilizou OneCRL, o seu sistema centralizado de bloqueo de certificados, para impedir que Firefox aceptase as autoridades intermedias comprometidas.

A distribución desta protección completouse o 17 de outubro, menos de tres horas despois de recibir a notificación, para os usuarios de Firefox con configuracións estándar.

Adicionalmente, Mozilla publicou Firefox 158.0.1 e as versións ESR 115.43.1 e 153.5.1, destinadas a estender a protección a configuracións que puidesen non recibir as actualizacións de OneCRL.

Tamén anunciou a eliminación da autoridade raíz emSign ECC Root CA - G3 do almacén de confianza de NSS 3.131.1, co obxectivo de protexer aplicacións que utilizan esta infraestrutura de certificados pero non reciben as actualizacións centralizadas de Firefox.

Google
Google confirmou que as claves privadas afectadas foran xeradas cunha aleatoriedade insuficiente e distribuíu unha actualización de CRLSet para bloquear as claves públicas das seis autoridades intermedias TLS comprometidas.

Este mecanismo permite rexeitar os certificados asociados a esas claves sen necesidade de actualizar ou reiniciar Chrome.

Google tamén distribuíu medidas equivalentes para dispositivos Android mediante Google Play Services.

Así mesmo, anunciou a retirada de emSign ECC Root CA - G3 do Chrome Root Store, prevista para o 27 de outubro de 2026. Esta medida pode afectar a servizos lexítimos que aínda utilicen cadeas de certificación dependentes desa autoridade raíz.

Os operadores destes servizos deberán comprobar os seus certificados e, cando corresponda, substituílos por outros emitidos baixo unha xerarquía de confianza admitida.

A transparencia dos certificados limita determinados escenarios de explotación
Un elemento relevante da resposta de Google é a comprobación realizada sobre os rexistros públicos de Certificate Transparency ou CT.

Google indica que, antes do bloqueo dos certificados intermedios afectados, non existían certificados TLS rexistrados que encadeasen coas seis autoridades intermedias comprometidas.

Chrome esixe, de maneira predeterminada, o cumprimento dos seus requisitos de Certificate Transparency para os certificados de confianza pública.

En consecuencia, os certificados fraudulentos non rexistrados non serían aceptados de maneira predeterminada por Chrome antes de que se distribuíse o bloqueo.

Esta circunstancia reduce significativamente o risco para navegadores e aplicacións que aplican correctamente os requisitos de CT.

Porén, non todos os clientes TLS utilizan os mesmos mecanismos de transparencia, revogación ou actualización da confianza.

Por este motivo, a ausencia de certificados fraudulentos nos rexistros CT non permite descartar por completo o risco para aplicacións, dispositivos ou sistemas que non aplicasen estas proteccións.

Risco residual en aplicacións e sistemas que xestionan os seus propios certificados
Aínda que os principais fabricantes reaccionaron rapidamente, a protección non depende exclusivamente dos navegadores web.

Existen aplicacións empresariais, bibliotecas criptográficas, dispositivos de rede, sistemas industriais, solucións integradas e servizos que utilizan almacéns de certificados independentes ou que non reciben automaticamente as actualizacións de confianza distribuídas polos fabricantes.

Nestes contornos, unha autoridade de certificación comprometida podería continuar sendo recoñecida como válida ata que se actualice o almacén correspondente ou se aplique unha medida equivalente de retirada de confianza.

Isto obriga a prestar especial atención aos sistemas que utilizan versións antigas de bibliotecas TLS, almacéns de confianza mantidos manualmente ou compoñentes que non dispoñen de mecanismos centralizados de revogación.

Tamén deben revisarse os servizos propios cuxos certificados dependan de emSign ECC Root CA - G3, dado que a retirada desta autoridade de determinados almacéns pode provocar erros de validación e problemas de dispoñibilidade.

A resposta debe equilibrar a retirada de confianza nos certificados comprometidos coa continuidade dos servizos lexítimos que poidan verse afectados.