A segurança de uma parte importante da infraestrutura de confiança da internet foi colocada em xeque após um grave incidente envolvendo a autoridade certificadora eMudhra. Uma falha no processo de geração e transferência de chaves criptográficas produziu certificados intermediários com material de segurança inadequado, permitindo que pesquisadores recuperassem chaves privadas que deveriam estar protegidas por controles rigorosos. O episódio expôs problemas nos procedimentos internos da empresa e levou os principais responsáveis pela infraestrutura de confiança dos navegadores a adotar medidas para bloquear os certificados afetados.
O caso ganhou novas proporções depois que uma segunda investigação identificou outros oito certificados intermediários comprometidos. Com isso, o total chegou a 16 certificados de autoridades certificadoras intermediárias afetados, abrangendo famílias criptográficas ECDSA e RSA. A descoberta também trouxe à tona falhas de controle que remontavam a 2025, incluindo sinais de alerta que não receberam uma investigação adequada. Diante da gravidade do episódio, a eMudhra anunciou sua saída do mercado global de certificados TLS de confiança pública.
O incidente é especialmente relevante porque uma autoridade certificadora não protege apenas seus próprios sistemas. Ela participa de uma cadeia de confiança utilizada por navegadores, sistemas operacionais, servidores e aplicações para determinar se uma conexão HTTPS ou uma assinatura digital pode ser considerada legítima. Quando as chaves privadas de uma autoridade intermediária perdem sua integridade, a segurança de toda essa estrutura pode ser colocada em risco.
O que deu errado com os certificados eMudhra: um script comprometeu a segurança criptográfica
Para compreender o incidente, é necessário entender o papel de uma Autoridade Certificadora (CA). Essas organizações emitem certificados digitais que associam uma identidade, como o domínio de um site, a uma chave criptográfica.
As autoridades certificadoras intermediárias ficam entre uma autoridade raiz e os certificados finais. Essa separação permite distribuir responsabilidades e limitar o uso direto das chaves mais importantes da infraestrutura.
No caso da eMudhra, o problema começou durante uma cerimônia de geração de chaves realizada em 30 de abril de 2025. A empresa precisava preparar material criptográfico para transferência entre diferentes localidades e ambientes operacionais.
Para executar essa tarefa, a equipe de operações de infraestrutura PKI desenvolveu um script personalizado em Python, responsável por encapsular as chaves em estruturas criptografadas (key wrapping) e permitir sua recuperação no destino (key unwrapping).
O procedimento deveria preservar integralmente a proteção oferecida pelos Hardware Security Modules (HSMs), dispositivos especializados utilizados para gerar, armazenar e operar chaves criptográficas em ambientes protegidos.
Entretanto, o script introduziu uma etapa inadequada de manipulação do material criptográfico no computador hospedeiro. O processo acabou produzindo e selecionando chaves diferentes das originais, comprometendo a garantia de integridade que deveria existir durante toda a operação.
É importante esclarecer uma distinção técnica: os HSMs não foram considerados defeituosos nem estavam ausentes do processo. As chaves originais foram geradas em equipamentos certificados. O problema estava no procedimento externo de manipulação e transferência, que não preservou corretamente a proteção do material criptográfico.
A situação contrariou os requisitos de segurança associados à transferência de chaves privadas, incluindo a seção 6.2.6 da Certificate Practice Statement (CPS) da própria eMudhra e os requisitos aplicáveis à infraestrutura pública de certificados.
A fraqueza bizarra nas chaves ECDSA dos certificados eMudhra
A primeira parte do incidente envolveu oito autoridades certificadoras intermediárias baseadas em ECDSA (Elliptic Curve Digital Signature Algorithm), um algoritmo de assinatura digital amplamente utilizado em conexões TLS por oferecer segurança criptográfica com chaves relativamente pequenas.
Em outubro de 2026, um pesquisador independente identificado como Wayne comunicou que havia conseguido recuperar as chaves privadas correspondentes a oito certificados intermediários da eMudhra.
A descoberta revelou uma fraqueza extraordinária: o material criptográfico publicado continha valores privados extremamente pequenos, em alguns casos reduzidos a apenas um byte. Uma chave com essa característica pode ser descoberta testando somente 256 possibilidades, considerando um único byte.
O problema elimina, na prática, a proteção que deveria ser proporcionada por uma chave criptográfica adequadamente gerada. Em vez de enfrentar um espaço de busca computacionalmente inviável, um atacante poderia testar todas as possibilidades em um intervalo insignificante.
A gravidade foi demonstrada pelo pesquisador, que apresentou provas de controle das chaves privadas correspondentes aos certificados afetados. A falha não representava apenas uma irregularidade de configuração: comprometia diretamente a capacidade de confiar nas assinaturas produzidas por aquelas autoridades intermediárias.
O comprometimento de memória nas chaves RSA e a segunda revogação
A investigação posterior revelou um segundo problema, desta vez envolvendo oito autoridades certificadoras intermediárias RSA-4096, identificadas nas séries G2B e G2C.
Diferentemente do caso ECDSA, a análise não demonstrou que essas chaves RSA tivessem sido reduzidas a valores facilmente recuperáveis. A integridade matemática das chaves permaneceu preservada, mas a maneira como foram manipuladas criou outro problema grave.
Durante o procedimento de reimportação, componentes privados do RSA, incluindo o expoente privado e os fatores primos utilizados na operação criptográfica, foram reconstruídos na memória volátil do processo Python executado no computador hospedeiro.
Isso significa que o material que deveria permanecer sob a fronteira de proteção do HSM passou pelo ambiente operacional do servidor. A empresa não conseguiu demonstrar retrospectivamente que o tratamento dessas informações respeitou integralmente os requisitos de proteção estabelecidos pela CPS, especialmente sua seção 6.2.6.
Essa distinção é fundamental: não foi demonstrada a recuperação das chaves RSA por terceiros, nem a quebra matemática de sua criptografia. O problema foi a impossibilidade de comprovar que a confidencialidade das chaves permaneceu protegida durante o procedimento.
Diante dessa incerteza, a eMudhra decidiu revogar também os oito certificados RSA, interrompendo sua utilização. Assim, a soma chegou a 16 autoridades certificadoras intermediárias afetadas: oito ECDSA e oito RSA.
A decisão demonstra por que a conformidade com os requisitos de segurança criptográfica não pode depender apenas da ausência de evidências de exploração. Em uma autoridade certificadora pública, a incapacidade de comprovar a proteção adequada de uma chave privada já representa um problema suficientemente sério para justificar medidas preventivas.
Sinais ignorados e o colapso da confiança pública nos certificados eMudhra
Um dos aspectos mais preocupantes do incidente é que a falha não surgiu completamente sem sinais anteriores.
Em junho de 2025, a eMudhra já havia enfrentado um problema relacionado à assinatura de listas de revogação de certificados, conhecidas como CRLs (Certificate Revocation Lists).
Essas listas permitem que navegadores e aplicações consultem quais certificados foram revogados antes do término de sua validade. Para que sejam confiáveis, precisam ser assinadas com a chave privada correspondente à autoridade certificadora responsável.
Na ocasião, foram identificadas CRLs assinadas com chaves que não correspondiam às chaves públicas presentes nos certificados intermediários envolvidos.
A empresa resolveu a inconsistência utilizando outros objetos criptográficos disponíveis para produzir assinaturas compatíveis. Entretanto, a investigação posterior revelou que essa solução corrigiu o sintoma sem identificar a origem do problema: a existência de objetos de chaves duplicados e a utilização do objeto recriado durante a cerimônia de geração.
Esse episódio representou uma oportunidade perdida de descobrir a falha aproximadamente 16 meses antes de sua divulgação pública.
A situação também levanta questionamentos sobre a efetividade dos controles internos e das auditorias independentes. A hierarquia havia passado por dois ciclos de auditoria, mas as verificações realizadas não identificaram a fraqueza das chaves ECDSA nem a divergência entre os objetos criptográficos originais e os utilizados na emissão dos certificados.
Google, Mozilla, Apple e Microsoft retiram a confiança dos certificados eMudhra
A resposta dos principais participantes do ecossistema digital foi rápida. Quando uma autoridade certificadora intermediária é considerada comprometida, não basta que a empresa responsável anuncie a revogação. É necessário garantir que navegadores e sistemas operacionais deixem de aceitar a cadeia de confiança afetada.
A Mozilla utilizou o mecanismo OneCRL para bloquear os certificados comprometidos no Firefox. A proteção foi distribuída automaticamente aos usuários com configurações padrão, sem exigir reinicialização ou atualização manual do navegador. A organização também disponibilizou versões atualizadas do Firefox e do Firefox ESR para ampliar a cobertura da correção.
O Google atuou por meio de seu programa de certificados raiz, coordenando medidas para retirar a confiança das autoridades intermediárias afetadas no ecossistema Chrome.
A Apple começou a bloquear os certificados comprometidos em 19 de outubro de 2026. A proteção alcançou automaticamente Safari, Mail e aplicações que utilizam os mecanismos de segurança e rede do sistema. A empresa também alertou administradores de macOS sobre possíveis diferenças no comportamento de ferramentas de linha de comando, como curl e git, que podem utilizar conjuntos de certificados locais.
Já a Microsoft publicou medidas emergenciais para Windows e Microsoft Edge. Em 20 de outubro, atualizou a lista de certificados considerados não confiáveis. Posteriormente, disponibilizou uma atualização fora do cronograma regular, em 26 de outubro, para remover certificados das cadeias afetadas, inclusive em sistemas que dependem de atualizações específicas para receber mudanças na lista de confiança.
A empresa também deixou claro que certificados fraudulentos produzidos com as chaves comprometidas poderiam se passar por sites legítimos ou permitir que programas maliciosos aparentassem possuir uma assinatura digital confiável.
Essas medidas mostram a importância da cooperação entre os programas de confiança dos navegadores. A segurança da WebPKI não depende exclusivamente de uma empresa, mas de uma rede de organizações capazes de responder rapidamente quando um elo da cadeia apresenta problemas.
A saída da eMudhra do mercado público de certificados TLS
Em 22 de outubro de 2026, a eMudhra anunciou que deixaria o mercado global de emissão de certificados TLS de confiança pública.
A decisão foi acompanhada pelo compromisso de transferir os clientes para outras autoridades certificadoras, evitando interrupções desnecessárias em serviços e aplicações que dependiam de seus certificados.
O processo de transição exigiu atenção especial a uma comunidade universitária norte-americana, que utilizava certificados da hierarquia G3 afetada. A empresa informou posteriormente que aproximadamente 30.800 certificados associados a esse ecossistema estavam envolvidos na transição.
A eMudhra também anunciou a contratação da KPMG para realizar uma avaliação independente do incidente e de seus procedimentos internos.
É importante destacar que a saída do mercado TLS público não significa o encerramento de todas as atividades da empresa. Segundo seus comunicados, os serviços de assinaturas digitais, eSign, emSigner, CertiNext, SecurePass e outras soluções empresariais utilizam infraestrutura separada e não foram afetados pelo incidente.
A retirada da confiança também será gradual. Google e Mozilla estabeleceram 16 de novembro de 2026 como marco para o encerramento da confiança em certificados emitidos sob a hierarquia emSign G1, enquanto a Apple definiu 30 de novembro para a remoção da hierarquia G1. A Microsoft também anunciou novas medidas de remoção de certificados raiz a partir de 16 de novembro.
Portanto, a revogação dos 16 intermediários não deve ser confundida com a retirada imediata de todas as raízes da empresa. São decisões distintas, tomadas para neutralizar o risco e concluir a transição dos clientes.
O impacto na segurança web e as lições para a infraestrutura de certificados
O incidente dos certificados eMudhra deixa uma advertência importante para administradores de sistemas, profissionais de DevOps e responsáveis por infraestrutura de segurança: processos criptográficos críticos não devem depender de scripts improvisados sem validação independente e controles rigorosos.
A utilização de HSMs é uma medida fundamental, mas não representa uma garantia absoluta quando procedimentos externos podem manipular material privado fora da fronteira protegida desses equipamentos.
Empresas que administram infraestrutura PKI precisam estabelecer controles capazes de verificar a correspondência entre as chaves originalmente geradas, as chaves utilizadas na emissão dos certificados e as informações publicadas nos repositórios de confiança.
Também é essencial implementar verificações automatizadas de integridade, revisar procedimentos de migração entre fabricantes de HSMs e investigar imediatamente qualquer divergência em assinaturas de CRLs ou operações criptográficas.
Para administradores Linux, o episódio reforça a importância de manter atualizados os pacotes de certificados raiz, as bibliotecas criptográficas e os navegadores utilizados nos ambientes corporativos. Também é recomendável revisar aplicações que utilizam armazenamentos próprios de certificados, pois nem todas acompanham automaticamente as alterações realizadas pelos principais fabricantes de sistemas operacionais.
Outro aprendizado importante envolve a resposta a incidentes. Uma anomalia aparentemente isolada pode representar um problema estrutural. Corrigir apenas o erro visível, sem investigar sua causa raiz, permite que falhas semelhantes permaneçam ocultas durante meses ou anos.
No caso da eMudhra, uma inconsistência identificada em 2025 não levou à descoberta da falha que posteriormente comprometeu a confiança em 16 autoridades intermediárias.
A confiança digital depende de processos verificáveis, não apenas de certificações e equipamentos de segurança. Uma autoridade certificadora precisa demonstrar que suas chaves são fortes, protegidas e utilizadas conforme os padrões estabelecidos.
Para a comunidade de software livre e os profissionais que administram servidores Linux, fica uma questão importante: sua infraestrutura possui mecanismos independentes para verificar certificados, acompanhar mudanças nas autoridades confiáveis e detectar anomalias na cadeia TLS?
