Chrome remove hoje a raiz da eMudhra, após chaves fracas em oito ACs intermediárias levarem ao bloqueio global
Nesta terça-feira (27/10), o Google prevê liberar a remoção da raiz emSign ECC Root CA G3, da eMudhra, para todos os dispositivos que usam o Chrome Root Store. Certificados legítimos ligados a essa raiz deixarão de funcionar no Chrome. As demais raízes da empresa seguem em avaliação.
Uma das chaves privadas que sustentavam a cadeia de confiança da eMudhra era o número 4. Revelada em 17 de outubro, a falha em oito ACs intermediárias da autoridade certificadora indiana chega ao ápice nesta terça-feira (27), quando o Chrome deixa de confiar na raiz emSign ECC Root CA G3 em todos os dispositivos.
Tudo começou quando o Chrome Root Program recebeu, às 18h05 (UTC) do sábado, 17 de outubro de 2026, o relato de um pesquisador de segurança sobre o comprometimento das chaves privadas de oito Autoridades Certificadoras (ACs) subordinadas da eMudhra.
O pesquisador, conhecido apenas como Wayne, provou o que dizia assinando a mensagem “We have a problem here” com cada uma das oito chaves. Segundo a Help Net Security, as chaves podiam ser recuperadas a partir dos próprios certificados públicos em menos de um segundo.
De acordo com o Google, a remoção da raiz atende aos sistemas que usam o repositório de confiança do Chrome mas não recebem as atualizações de revogação do navegador.
A empresa orientou que operadores de sites com certificados encadeados à emSign ECC Root CA G3 adquiram e instalem imediatamente um novo certificado TLS de outra hierarquia de infraestrutura de chaves públicas (PKI) presente no Chrome Root Store. O Google também reconheceu que alguns certificados legítimos encadeados a essa raiz vão parar de funcionar no Chrome.
Como uma chave forte virou o número 4
A origem do problema está em uma cerimônia de geração de chaves realizada há um ano e meio. Em 30 de abril de 2025, durante a geração de 24 ACs subordinadas sob a emSign Root TLS CA G3, com assinatura cruzada da Comodo AAA Certificate Services, uma falha no processo criou um segundo conjunto de chaves P-384 fracas em uma etapa de encapsulamento e desencapsulamento, e essas chaves acabaram usadas em oito certificados intermediários.
O erro tem detalhes que desafiam qualquer protocolo de segurança. O script gerou chaves fracas com rótulos parecidos com os das chaves legítimas, e a equipe escolheu as erradas ao preparar os certificados.
Segundo relatos, em vez de investigar por que as chaves não correspondiam, a equipe reconfigurou o assinante da lista de revogação para usar as chaves fracas e deu o problema como resolvido. Uma das chaves privadas, a da EM OV TLS CA G3C, era literalmente o número 4; outras valiam 56, 115, 155, 156 e 230.
Das oito ACs afetadas, seis serviam à segurança de sites (TLS) e duas à assinatura de código. Em comunicado, a própria empresa admitiu a responsabilidade: “A falha foi nossa” (tradução livre), disse a eMudhra em seu pedido público de desculpas.
Entropia, o elo que nenhum algoritmo protege
Como o Crypto ID mostrou em 21 de outubro, ao explicar o bloqueio emergencial do Go noticiado na véspera, o algoritmo P-384 não foi quebrado.
A cerimônia de geração de chaves usou HSMs da Entrust e da Utimaco, com certificação FIPS 140-2 Nível 3, mas as oito chaves comprometidas tinham valores inferiores a 256, quando deveriam ter sido sorteadas em um espaço de aproximadamente 2 elevado a 384 possibilidades.
A própria eMudhra afirmou que os equipamentos não parecem ser a origem da falha, que estaria no script e nos procedimentos da cerimônia. Coincidentemente, entre 17 e 18 de outubro, mesmos dias em que o problema da eMudhra veio à tona, a rede blockchain Qubic teve 1.404 carteiras comprometidas por uma falha da mesma natureza: segredos criptográficos gerados com números aleatórios inseguros.
Ao analisar o ataque à Qubic em ID Talk publicado pelo Crypto ID em 22 de outubro, Marco Zanini, CEO da DINAMO Cyber Security Company, foi direto ao ponto:
“A geração segura de chaves passa por um processo de alta entropia que, neste caso, não foi eficiente.” E completou: “Esse processo deve ser feito com tecnologias construídas para isso, seguindo as melhores práticas e certificações no mercado de segurança. As empresas, financeiras ou não, parecem não ter conhecimento necessário internamente para avaliar as soluções com esse nível de profundidade.”
O caso da eMudhra mostra a outra face da mesma lição: HSMs certificados são condição necessária, mas não suficiente, se os scripts, os procedimentos e as auditorias não validarem cada chave gerada.
Resposta em horas, não em dias
A reação dos programas de raiz foi exemplar. Às 19h45 (UTC) do próprio dia 17, o Chrome distribuiu uma atualização de CRLSet bloqueando as chaves das intermediárias, o que, segundo o Google, aconteceu 1 hora e 40 minutos depois do relato. O Google afirmou que os usuários do Chrome ficaram protegidos de imediato, sem precisar atualizar ou reiniciar o navegador.
Na sequência, a eMudhra revogou as oito intermediárias em 18 de outubro; em 20 de outubro, a Microsoft bloqueou os certificados, saíram as versões corrigidas de Go, Firefox e NSS, e a Mozilla retirou a confiança na emSign ECC Root CA G3. A Apple havia agido em 19 de outubro.
Até agora, não há indício de uso malicioso.
A eMudhra declarou não ter conhecimento de qualquer evidência de que as chaves fracas tenham sido recuperadas ou exploradas antes da divulgação. O Chrome Root Program informou que nenhum certificado emitido pelas seis intermediárias de TLS havia sido registrado em logs de Transparência de Certificados antes do bloqueio. Por isso, segundo o Google, nenhum certificado fraudulento dessas ACs poderia ter sido usado contra clientes que exigem Transparência de Certificados, como o Chrome em sua configuração padrão. Ainda assim, não se sabe se alguém recuperou e usou as chaves fracas nos 17 meses anteriores à descoberta.
Quem é atingido hoje
O impacto da remoção da raiz vai além dos certificados comprometidos. O Chrome contabilizou cerca de 30,8 mil certificados ainda válidos encadeados à raiz em 21 de outubro, quase todos emitidos pelo InCommon, serviço de certificados voltado ao ensino superior. Esses sites, sem nenhuma relação com a falha, passam a exibir erro no Chrome se não trocarem de hierarquia.
O risco mais silencioso, porém, está fora dos navegadores. A Kudelski Security aponta como potencialmente afetados os clientes TLS que não consomem dados de revogação nem de Transparência de Certificados: ferramentas de desenvolvimento, pacotes que trazem seus próprios repositórios de confiança, o ecossistema Python, contêineres, distribuições Linux desatualizadas, dispositivos embarcados e de Internet das Coisas (IoT).
Uma imagem Docker congela seu pacote de ACs no momento da construção, de modo que toda imagem gerada antes da correção continua confiando nas intermediárias comprometidas até ser reconstruída. A equipe do Go chegou a codificar a desconfiança nas oito chaves diretamente na biblioteca padrão.
Para quem desenvolve, a recomendação é atualizar bibliotecas e runtimes. A correção já está disponível no certifi (Python) a partir da versão 2026.10.23, no Node.js nas versões 22.23.4, 24.22.1 e 26.12.1, no Go 1.27.3 e 1.26.10 e no Electron 44.9.3, 43.8.3 e 42.11.18.
Da crise à saída em cinco dias
O desfecho empresarial veio rápido. Em 22 de outubro, em Bengaluru, a eMudhra anunciou que seu conselho decidiu sair voluntariamente do negócio global de certificados SSL/TLS.
O presidente do conselho, Srinivasan, afirmou que a empresa revogou as ACs afetadas em até 14 horas após a descoberta e que o SSL/TLS global responde por cerca de 1% da receita. A companhia também atribuiu a decisão à concorrência de certificados gratuitos e a custos crescentes de conformidade, e classificou a repercussão nas redes sociais como desproporcional ao peso do segmento em seus negócios.
O mercado reagiu com dureza. As ações da empresa caíram 40% em dois dias, segundo o Business Standard.
O que a eMudhra mantém
A saída do mercado de SSL/TLS não significa o fim da eMudhra. A companhia deixa apenas a emissão global de certificados SSL/TLS e mantém seus serviços de assinatura digital e de identificação, além dos demais negócios de certificação e assinatura.
Segundo a empresa, a infraestrutura global de SSL/TLS opera separada das outras atividades. A retirada será gradual: os serviços de revogação e de consulta de status seguirão funcionando até que todos os certificados SSL/TLS já emitidos expirem ou sejam substituídos, e as raízes RSA G1 continuarão atendendo os clientes durante a transição.
A eMudhra também se comprometeu a entregar aos programas de raiz dos navegadores um relatório completo sobre a causa do incidente.
A permanência dessas raízes, porém, não está garantida: o Google investiga se as demais ACs da empresa devem continuar no Chrome Root Store, enquanto a Mozilla decidiu, por ora, manter a confiança na emSign Root CA G1.
A lição para o mercado brasileiro
O caso não é o primeiro choque recente no ecossistema de ACs públicas. O Chrome já havia deixado de confiar em certificados da Entrust depois que o Google apontou problemas na atuação daquela autoridade certificadora. A diferença agora é a velocidade: entre a descoberta e a saída do mercado, passaram-se cinco dias.
Para as organizações brasileiras, a mensagem é dupla.
Primeiro, ninguém controla aquilo que não enxerga: inventariar certificados, cadeias e repositórios de confiança, inclusive em contêineres, aplicações legadas e dispositivos conectados, deixou de ser boa prática e virou condição de continuidade operacional. Segundo, a autoridade certificadora pode sair do mercado antes dos seus certificados expirarem, e a troca de fornecedor precisa ser planejada, automatizada e testada antes da crise.
O contexto regulatório reforça essa urgência
Desde 2023, o Crypto ID acompanha a redução da validade dos certificados SSL/TLS, quando a proposta em debate ainda era de 90 dias e já se alertava que a automação da emissão, da revogação e da renovação deixaria de ser opcional.
O cenário se confirmou: em 11 de abril de 2025, o CA/Browser Forum aprovou o ballot SC-081v3, que reduziu a validade máxima dos certificados TLS públicos para 200 dias em 15 de março de 2026, fixa 100 dias a partir de 15 de março de 2027 e chega a 47 dias em 15 de março de 2029.
Somada à migração para a criptografia pós-quântica, essa mudança torna a agilidade criptográfica e a gestão automatizada do ciclo de vida dos certificados uma exigência de negócio. Toda a confiança da internet depende de uma sequência de números que ninguém deveria conseguir adivinhar. No caso da eMudhra, um deles era 4..
Sobre a empresa
A eMudhra Limited foi fundada em 2008 e tem sede em Bengaluru, na Índia. Listada nas bolsas indianas BSE e NSE, atua em serviços de confiança digital, como certificados de assinatura digital, PKI gerenciada, autenticação e plataformas de assinatura eletrônica. Atuava como autoridade certificadora pública para SSL/TLS sob a marca emSign e mantém operações nos Estados Unidos, Europa, Oriente Médio, África e Ásia.
Glossário
AC intermediária: autoridade certificadora subordinada a uma AC raiz, que emite os certificados usados por sites e aplicações. Sua chave privada pode assinar certificados aceitos como legítimos para qualquer domínio.
AC raiz: topo da cadeia de confiança. Seu certificado vem pré-instalado em navegadores e sistemas operacionais, e tudo o que ela assina, direta ou indiretamente, é considerado confiável.
Chave privada: parte secreta de um par de chaves criptográficas. Quem a possui pode assinar em nome do titular; por isso, deve ser gerada com aleatoriedade suficiente e protegida em hardware.
Cerimônia de geração de chaves: procedimento formal, auditado e documentado em que uma AC gera suas chaves em módulos de segurança de hardware (HSM), com testemunhas e controles rigorosos.
P-384: curva elíptica padronizada pelo NIST (Instituto Nacional de Padrões e Tecnologia dos Estados Unidos), usada em criptografia de curvas elípticas (ECC) com nível de segurança equivalente a 192 bits, quando a chave é gerada corretamente.
CRLSet: lista compacta de certificados revogados que o Google distribui diretamente ao Chrome, sem exigir atualização ou reinício do navegador.
Transparência de Certificados (CT): sistema de registros públicos e auditáveis em que os certificados TLS precisam ser publicados para serem aceitos pelo Chrome, permitindo detectar emissões indevidas.
Root Store: repositório de certificados raiz considerados confiáveis por um navegador ou sistema operacional, mantido por programas como o Chrome Root Program e o Mozilla Root Store Program.
Acesse aqui e saiba tudo sobre TLS, o protocolo de segurança que garante o sigilo das informações e identifica empresas, dispositivos e objetos no mundo eletrônico.
ID Talk | Qubic retoma operações após ataque e Marco Zanini analisa falha criptográfica
Falha na geração de chaves na Índia explica bloqueio emergencial do Go conforme noticiamos ontem
Go bloqueia oito chaves de certificação digital em atualização de emergência
DigiCert: A vida útil de certificados TLS será oficialmente reduzida para 47 dias
Certificados SSL/TLS de 47 dias até 2029: calendário oficial
Somos a voz influente no ecossistema brasileiro de segurança da informação e identificação digital, e nosso propósito é contribuir ativamente para a educação e o debate sobre esses temas.
Fale com a gente: +55 11 9 9286 7046 ou contato@cryptoid.com.br
