Uma falha na geração de chaves dos certificados da eMudhra afetou oito autoridades certificadoras intermediárias, levando Chrome e Firefox a bloquear as chaves envolvidas. O CERT-In, órgão de resposta a incidentes da Índia, publicou o alerta CIAD-2026-0050 em 21 de outubro de 2026. O risco é permitir a criação de certificados falsos em sistemas que ainda confiem nessa cadeia, mas isso não equivale a uma quebra geral do HTTPS.
Google e Mozilla já aplicaram proteções. A eMudhra afirma que não houve invasão da infraestrutura ou vazamento de dados. Em 22 de outubro, a Reuters noticiou que a empresa decidiu se retirar do negócio global de certificados SSL/TLS. Veja o que realmente aconteceu e o que usuários e administradores devem verificar.
O que aconteceu com os certificados da eMudhra?
Uma autoridade certificadora (CA) participa da cadeia de confiança que permite ao navegador identificar o site com o qual está se comunicando. Uma CA intermediária recebe autorização de uma raiz confiável para assinar certificados de outras entidades. Se a chave privada dessa intermediária puder ser recuperada, sua identidade poderá ser imitada.
O aviso oficial do CERT-In descreve oito intermediárias comprometidas: seis destinadas a TLS/HTTPS e duas à assinatura de código. As chaves privadas de curva elíptica P-384 foram produzidas com aleatoriedade insuficiente; seus valores eram menores que 256, permitindo recuperá-las a partir das chaves públicas. A falha estava na geração das chaves, não no algoritmo P-384 em si.
O CERT-In registrou a revogação das oito intermediárias pela eMudhra em 18 de outubro, após a divulgação responsável iniciada em 17 de outubro.
Como a falha poderia afetar sites HTTPS?
No cenário descrito pelas equipes de segurança, alguém que obtivesse uma dessas chaves poderia produzir certificados falsos para domínios que não controla. Caso também conseguisse interceptar uma conexão e o dispositivo da vítima ainda confiasse nessa CA, poderia tentar se passar por um site legítimo e ler ou modificar informações.
Esse é um risco técnico potencial, não um ataque comprovado a todos os usuários. Segundo o Google, os registros públicos de Certificate Transparency não continham certificados TLS emitidos pelas seis intermediárias afetadas antes do bloqueio. O CERT-In afirmou que os comunicados disponíveis até 21 de outubro não estabeleciam exploração maliciosa confirmada.
Há ainda uma consequência distinta: um serviço legítimo que dependa da raiz que deixará de ser confiável pode começar a mostrar erro de certificado. Isso não significa necessariamente que o site foi invadido; significa que sua cadeia pode precisar ser substituída. A Cloudflare detalhou esse impacto operacional em sua análise técnica.
O que Chrome, Android e Firefox fizeram para proteger os usuários?
| Plataforma | Proteção confirmada | Situação em 22/10/2026 |
|---|---|---|
| Chrome | Bloqueio de chaves por CRLSet/SPKI | Aplicado em 17/10, sem exigir atualização ou reinício |
| Android compatível | Bloqueio equivalente via Google Play Services | Distribuído pelo Google para dispositivos suportados |
| Firefox | Bloqueio via OneCRL | Distribuído em 17/10 para configurações padrão |
| Firefox e ESR | Versões com proteção incorporada | Firefox 158.0.1 e ESR 115.43.1 / 153.5.1 |
| Firefox para Android | Correção adicional da OneCRL embutida | Versão 158.0.2 lançada em 21/10 |
| Chrome Root Store | Retirada da raiz emSign ECC Root CA - G3 | Distribuição prevista para 27/10, ainda não concluída nesta verificação |
O Google informou que a ação inicial bloqueia as chaves públicas das intermediárias por seus identificadores SPKI. A Mozilla explicou que o OneCRL protegeu instalações padrão do Firefox mesmo sem atualizar o aplicativo; versões específicas foram lançadas para clientes com configurações que não recebiam o bloqueio remoto.
A remoção da raiz emSign ECC Root CA - G3 no Chrome Root Store está prevista para 27 de outubro de 2026. Não deve ser confundida com os bloqueios já realizados. A mudança de confiança da raiz pode exigir que administradores substituam certificados de serviços legítimos dependentes dela.
A eMudhra confirmou vazamento de dados?
Não. Em comunicado divulgado em 21 de outubro, a eMudhra afirmou que sua infraestrutura não foi comprometida, não houve vazamento de dados e os controles físicos e lógicos permaneceram íntegros. A empresa atribuiu o problema a uma etapa da cerimônia de geração das chaves realizada em abril de 2025 e informou que ainda investigava a causa.
A companhia também declarou que as oito intermediárias não haviam emitido certificados finais e que seus serviços indianos de assinatura digital DSC e eSign utilizam infraestrutura separada. Essas declarações são a posição da empresa; não equivalem, por si só, a uma auditoria independente de todos os sistemas.
Em 22 de outubro, a Reuters noticiou que a eMudhra decidiu abandonar voluntariamente o segmento global de certificados SSL/TLS. O negócio foi descrito como uma pequena parcela da receita da empresa. Até esta redação, a decisão é apresentada com atribuição ao veículo jornalístico.
O que usuários comuns devem fazer agora?
Mantenha Chrome, Firefox e o sistema operacional atualizados, usando os canais oficiais dos fornecedores.
No Android, confira as atualizações do navegador, do sistema e dos serviços do Google compatíveis com o aparelho.
Se aparecer aviso de certificado inválido, não o ignore e não escolha continuar apesar do alerta apenas para entrar no site.
Em aplicativos antigos ou de uso corporativo, procure orientação do fornecedor antes de assumir que o software já recebeu a proteção.
Não apague certificados do Windows manualmente nem altere a loja de confiança apenas porque viu o nome eMudhra em uma notícia.
Não há indicação geral para trocar senhas apenas por causa desse aviso. Se houver alerta concreto de conta ou serviço comprometido, siga as instruções específicas do provedor responsável.
O que administradores e desenvolvedores precisam verificar?
Inspecione a cadeia TLS utilizada pelos domínios, APIs, proxies, servidores de origem e conexões mTLS sob sua responsabilidade.
Identifique dependências dos intermediários afetados ou da raiz emSign ECC Root CA - G3. Considere também cadeias alternativas ou assinadas por mais de uma autoridade.
Caso a cadeia deixe de ser confiável para seus clientes, providencie a reemissão e implantação de certificado em uma hierarquia não afetada.
Atualize bibliotecas TLS, pacotes de certificados confiáveis, containers, dispositivos e runtimes com lojas de confiança próprias conforme as instruções dos fornecedores.
Mantenha a validação de certificados ativada. Desabilitar verificação TLS para fazer um erro desaparecer não é correção de segurança.
Confirme a dependência real de cada serviço antes de classificá-lo como vulnerável ou interromper sua operação.
Esse incidente envolve confiança em autoridades certificadoras. É diferente das falhas de implementação tratadas pela DEVM no artigo sobre vulnerabilidades do curl 8.23.0; atualizar bibliotecas e avaliar cadeias são controles complementares, não explicações para uma mesma falha.
Como consultar a cadeia de certificados HTTPS no Chrome
Para compreender como a confiança é exibida, é possível observar um certificado público de um domínio que você opera, sem executar exploração nem alterar o navegador. A sequência abaixo é uma orientação prática e ainda não representa um teste realizado pela DEVM.
Abra o Chrome e visite chrome://settings/help para verificar a versão e o estado de atualização.
Em outra aba, abra um domínio sob sua administração, como https://devm.com.br.
Pressione F12 e procure a guia Security nas Ferramentas do Desenvolvedor.
Selecione a opção View certificate ou equivalente; o nome varia conforme a versão do navegador.
Examine o emissor, as autoridades intermediárias e a raiz mostrada no caminho de certificação. Se a raiz não for emSign ECC Root CA - G3, isso apenas indica que aquela cadeia observada não depende da raiz citada.
Registre a data, a versão do navegador e o domínio consultado, ocultando dados pessoais antes de compartilhar capturas.
Visualizar o certificado de um site não reproduz a falha da eMudhra e não permite concluir que outros serviços estejam protegidos. Não mude configurações de confiança nem ignore erros de certificado para fazer a demonstração.
O que muda daqui para frente?
Os bloqueios das intermediárias já reduziram a exposição em navegadores atualizados. O próximo marco divulgado pelo Google é 27 de outubro de 2026, quando está prevista a chegada da retirada da raiz G3 aos clientes do Chrome Root Store. Até lá, empresas responsáveis por serviços que dependam dessa hierarquia devem conferir certificados e planejar a migração quando necessária.
Para o usuário comum, a orientação permanece atualizar os programas e não ignorar avisos HTTPS. O risco depende de quais certificados a aplicação aceita, não do simples fato de um site exibir um cadeado.
