Imagem editorial original gerada para o Plugged Ninja. Arte abstrata, sem texto.
Oito certificados de autoridade certificadora (CA) intermediária da indiana eMudhra foram revogados em 18 de outubro de 2026 porque suas chaves privadas podiam ser recalculadas por qualquer pessoa a partir dos certificados públicos. A causa não foi invasão: as chaves foram geradas com entropia insuficiente e, segundo a análise da Mozilla, correspondem a números inteiros menores que 256 — valores que um atacante descobre por força bruta quase instantaneamente.
O caso foi reportado por um pesquisador independente em 17 de outubro e tratado como emergência pelos programas de raiz dos principais navegadores. Em menos de duas horas o Chrome já bloqueava os certificados; em pouco mais de três, a Mozilla concluía o bloqueio no Firefox. Na semana seguinte, Chrome e Mozilla decidiram remover em caráter emergencial a confiança na raiz emSign ECC Root CA – G3, acima desses intermediários, e a eMudhra anunciou a saída do mercado de TLS publicamente confiável.
A análise de resposta publicada pela Unit 42, da Palo Alto Networks, em 22 de outubro, consolidou o episódio para equipes corporativas. O que o torna relevante além do universo de clientes da eMudhra é a natureza da falha: não estava no protocolo, nem no HSM, nem na criptografia, mas no processo de geração de chaves — e passou por duas auditorias sem ser detectada por cerca de 18 meses.
Uma autoridade certificadora intermediária existe para assinar certificados de sites em nome de uma raiz confiável. Quem possui a chave privada de uma intermediária pode emitir certificados TLS válidos para qualquer domínio — seubanco.com.br, um portal de governo, o endpoint de uma API interna — e esses certificados serão aceitos por qualquer cliente que confie naquela cadeia. É a condição ideal para interceptação de tráfego (ataque de intermediário), personificação de serviço e sequestro de sessão.
No caso da eMudhra, não foi preciso roubar nada. As oito chaves afetadas são do tipo ECDSA sobre a curva P-384; em condições normais, a chave privada é um número inteiro aleatório em um intervalo astronômico. A Mozilla relata ter recuperado as chaves de forma independente às 21h48 UTC de 17 de outubro, sem conhecer o método do pesquisador, e observa que bastaria gerar as “primeiras” 256 chaves P-384 para obtê-las.
É um erro de classe conhecida — falhas de entropia já produziram episódios como o do gerador de números aleatórios do OpenSSL no Debian, em 2008, e o ROCA, em 2017. A diferença aqui é a posição na hierarquia: o defeito atingiu chaves de CA intermediária já incluídas em lojas de raiz de navegadores.
A explicação técnica, atribuída à própria eMudhra nos registros públicos, é a seguinte. Em 30 de abril de 2025, uma cerimônia de geração de chaves produziu 24 certificados intermediários distribuídos em três séries, com chaves RSA de 4.096 bits e P-384, para finalidades de validação de domínio (DV), de organização (OV), estendida (EV) e assinatura de código (CS). A cerimônia incluía um desvio aprovado para testar o empacotamento e desempacotamento de chaves com vistas a exportação.
Durante esse teste, uma falha de código criou um segundo par de chaves, mais fraco, no HSM Utimaco usado na cerimônia. Como os rótulos das chaves eram semelhantes, a equipe acabou usando as chaves fracas para gerar as requisições de assinatura de certificado, que a raiz assinou. As mesmas requisições também foram enviadas à Sectigo para assinatura cruzada — motivo pelo qual existem duas listas de certificados afetados.
Segundo a eMudhra, as chaves RSA foram geradas por caminho diferente e não foram atingidas, e as séries A e A-1 foram geradas em HSMs Entrust para uso exclusivo na Índia — a Mozilla registra que ainda não avaliou essas chaves. A nota de liderança da empresa atribui o problema a um “erro de script”, mas sua atualização posterior afirma que a causa raiz exata não está confirmada e que um relatório completo será publicado no CCADB. O mecanismo acima é, portanto, a versão do emissor, não uma conclusão independente.
Os oito intermediários revogados pela eMudhra, com o motivo caCompromise, entre 09h24 e 09h38 UTC de 18 de outubro, são:
Os seis intermediários de TLS eram confiados por Chrome, Mozilla, Microsoft e Apple; os dois de assinatura de código, pela Microsoft. A Sectigo concluiu a revogação das versões assinadas cruzadamente sob a raiz AAA Certificate Services em 19 de outubro. As impressões digitais SHA-256 de todos os dezesseis certificados estão listadas no registro público da Mozilla — vale conferi-las ali, e não em reproduções de terceiros, antes de montar qualquer regra de detecção.
A velocidade da reação é o aspecto mais instrutivo do episódio. Todos os horários estão em UTC, em 17 de outubro de 2026, salvo indicação:
O bloqueio por SPKI é o detalhe técnico que mais protege o usuário: como atinge a chave pública, e não o certificado individual, qualquer certificado que compartilhe aquelas chaves é rejeitado — inclusive os assinados cruzadamente e os que ainda não existiam no momento do bloqueio. Os registros de Transparência de Certificados (CT) também foram ajustados para rejeitar certificados que encadeiem nas CAs comprometidas.
Aqui é preciso separar com cuidado o que está confirmado do que é alegação. A eMudhra afirma que sete dos oito intermediários nunca entraram em produção, que o único em operação não havia emitido nenhum certificado de entidade final e que os registros do crt.sh corroboram isso. O Google declara que nenhum certificado TLS encadeando nesses intermediários havia sido registrado em CT antes do bloqueio, o que significa que certificados fraudulentos originados dali não poderiam ter sido usados contra clientes que exigem CT — caso do Chrome e de parte dos aplicativos Android.
Em paralelo, um comentário no registro público da Mozilla relata que 107.107 certificados assinados com seis das oito chaves foram registrados em CT entre 20 e 21 de outubro, incluindo 106.050 certificados de prova de conceito com um nome alternativo apontando para google.com. Esses registros são posteriores à divulgação e têm caráter demonstrativo — mostram que as chaves estavam, de fato, ao alcance de terceiros. A alegação não foi verificada no próprio registro e a eMudhra não respondeu a ela. Não há, nas fontes consultadas, nenhum indício de uso malicioso antes da divulgação; a eMudhra declara não ter conhecimento de evidência nesse sentido.
Segundo o Chrome, cerca de 30.800 pré-certificados não expirados encadeiam na raiz emSign ECC Root CA – G3, a maioria emitida por CAs subordinadas da InCommon e apenas 18 pelos intermediários da eMudhra. A empresa estima cerca de 30 mil certificados a migrar, aproximadamente 97% via ACME, para sua hierarquia RSA G1, e descreve o impacto como limitado a um ecossistema de clientes nos Estados Unidos; afirma também que a chave privada da raiz não foi comprometida — a remoção é precaução dos programas de navegador. O efeito colateral é que certificados legítimos nessa cadeia deixam de funcionar no Chrome depois da remoção, e quem está nela precisa instalar um novo certificado de outra hierarquia presente na Chrome Root Store. A eMudhra informa estar emitindo substituições sem custo, com a Sectigo como opção.
As orientações da Unit 42 valem mesmo para quem acredita não ser cliente da eMudhra, porque certificados chegam a ambientes por caminhos indiretos:
certifi do Python, imagens-base de contêiner e pacotes de aplicativos móveis.O episódio tem dois lados. O que funcionou foi o ecossistema de governança de PKI: um pesquisador externo encontrou a falha, o relato percorreu dois programas de raiz em minutos, a verificação foi independente, o bloqueio alcançou usuários sem exigir atualização de navegador e a Transparência de Certificados permitiu afirmar com base em registro público que não houve emissão prévia. É provavelmente a resposta coordenada mais rápida já documentada para um comprometimento de chave de CA.
O que falhou foi mais fundo. Uma cerimônia de geração de chaves com desvio de procedimento aprovado produziu material criptográfico trivialmente quebrável, rótulos parecidos levaram ao uso do par errado, a raiz assinou, duas auditorias não detectaram e o defeito permaneceu por cerca de 18 meses em certificados distribuídos a lojas de raiz globais. Nenhum controle de conformidade existente verificava a qualidade real da chave depois de gerada — e esse é o ponto que o setor precisa tratar: verificação automatizada de entropia de chaves de CA antes da inclusão em programas de raiz é uma checagem barata que não existia.
O que observar a seguir: o relatório de causa raiz prometido ao CCADB, a decisão do Chrome sobre a permanência das demais CAs da empresa em sua loja de raiz, a avaliação ainda pendente das chaves RSA e das séries geradas para a Índia, e a conclusão da migração dos cerca de 30 mil certificados. Para administradores brasileiros, a ação imediata é simples e vale a hora de trabalho: varrer os repositórios de confiança da própria infraestrutura antes de descobrir a dependência durante um incidente.
A medição instrumentou o navegador no nível do motor JavaScript para atribuir cada fluxo de…
Pesquisadores do Google e de Cornell propõem alternar atendimento e uma fase offline em que…
A Microsoft detalhou como três arquivos de inicialização do Python embutidos no pacote recolhiam chaves…
Com o driver de RDMA do macOS 26.2 sobre Thunderbolt 5, quatro estações com M5…
O sistema do Google segmenta o documento, distribui computação por densidade de informação e verifica…
O grupo chinês mapeado pela Sophos carrega um backdoor derivado do Meterpreter a partir de…