A chave era 4: quem decide em quais sites seu software confia

Este artigo foi traduzido automaticamente. A versão original está disponível em inglês.

Última atualização: 25 de outubro de 2026 · 21 min de leitura

Temos um problema aqui

No sábado, 17 de outubro de 2026, às 18h05 UTC, o programa de certificados raiz do Chrome recebeu um relato de um pesquisador de segurança identificado publicamente apenas como Wayne. Ele afirmava ter as chaves privadas de oito autoridades certificadoras operadas pela eMudhra, uma empresa de capital aberto sediada em Bangalore, na Índia. Para provar, tinha usado cada uma das oito chaves para assinar a mesma mensagem curta: “Temos um problema aqui – Wayne.”

Ele não precisara invadir nada. Quando a notícia se espalhou, o pesquisador de segurança Scott Helme descreveu como eram as chaves. Uma delas era simplesmente o número 4. Outras duas eram 56 e 115. Helme disse que havia recuperado todas elas a partir dos certificados públicos correspondentes, em seu laptop, e que isso levou menos de um segundo. Uma verificação independente feita por jornalistas confirmou que a chave privada por trás da “EM OV TLS CA – G3C” da eMudhra era 4.

As oito eram autoridades certificadoras intermediárias, a camada de trabalho de uma empresa de certificados, aquela que assina credenciais para outras pessoas. Seis delas estavam autorizadas a emitir certificados para sites, e essas seis eram reconhecidas como confiáveis pelos programas de certificados raiz do Chrome, da Mozilla, da Microsoft e da Apple. As outras duas serviam para assinatura de código, os certificados que os fabricantes de software usam para assinar seus programas, e eram reconhecidas pela Microsoft. Suas chaves tinham sido geradas de forma incorreta, de modo que qualquer pessoa que soubesse onde procurar poderia calculá-las a partir dos próprios certificados, que são públicos por definição. Isso era possível desde que os certificados foram criados, em abril de 2025.

Às 19h45 UTC, uma hora e quarenta minutos depois de o relato chegar, o Chrome já havia confirmado as descobertas e enviado um bloqueio a seus usuários. Ninguém precisou instalar uma atualização nem reiniciar o navegador.

A rapidez importava por causa do que uma chave dessas permite fazer. Alguém com qualquer uma das seis chaves de sites, e capaz de interceptar a conexão de uma pessoa, poderia apresentar um certificado forjado de um banco, de um serviço de e-mail ou de qualquer outro site, fosse qual fosse a empresa de certificados usada pelo site verdadeiro, e um software que confiasse na cadeia da eMudhra o aceitaria. Duas proteções principais estavam no caminho: um sistema público de registro chamado Certificate Transparency, que alguns softwares exigem e muitos outros não, e os bloqueios que cada software recebesse a tempo.

Se um certificado forjado teria funcionado dependia de decisões que normalmente ninguém vê: quem responde por um site, quem decide que esse fiador merece crédito e com que rapidez essa confiança pode ser retirada quando se descobre que o fiador está quebrado.

O que um certificado garante

Um certificado de site é um pequeno documento assinado que vincula um nome, como o endereço de um banco na web, a uma chave pública. Chaves públicas vêm em pares com chaves privadas. A chave privada fica em segredo e produz assinaturas digitais; a chave pública permite a qualquer um verificar se uma assinatura veio da sua parceira. Quando seu navegador se conecta a um site, o site prova que tem a chave privada correspondente à chave pública do seu certificado. O certificado em si afirma que essa chave pública pertence a esse nome, e uma autoridade certificadora, ou AC, responde por essa afirmação ao assiná-la.

Antes de assinar um certificado de site, a AC precisa verificar se o solicitante controla o domínio. Um dos métodos aprovados é entregar ao solicitante um valor aleatório e depois procurá-lo nos registros DNS do domínio, a agenda pública de endereços da internet, onde só quem controla o domínio poderia tê-lo colocado. A AC também pode confirmar que o solicitante de fato possui a chave privada que quer certificar, com um teste técnico chamado prova de posse, embora a norma subjacente também lhe permita confiar na palavra do solicitante.

Nenhum navegador conseguiria verificar sozinho cada AC do mundo, por isso a confiança é delegada em cadeia. No topo ficam os certificados raiz, guardados numa lista chamada repositório de confiança, que vem embutida no sistema operacional ou no navegador. As raízes autorizam ACs intermediárias, e as intermediárias emitem os certificados que os sites usam. Quando o software vê o certificado de um site, segue as assinaturas de baixo para cima, do site a uma intermediária e daí a uma raiz, e só aceita o site se a cadeia terminar numa raiz do seu repositório, se todas as assinaturas forem válidas, se o certificado estiver dentro do prazo de validade e cobrir o nome visitado, e se nenhuma das outras regras do software o proibir.

Os programas de certificados raiz, mantidos por fabricantes de sistemas operacionais e navegadores como Apple, Google, Microsoft e Mozilla, avaliam as autoridades certificadoras e decidem quais raízes entram no repositório. É por isso que a chave privada de uma intermediária vale tanto. A menos que tenha sido restrita a determinados nomes, e as da eMudhra não tinham sido, uma intermediária pode assinar um certificado para qualquer domínio, e esse certificado é validado até uma raiz confiável. A chave da própria raiz pode ficar trancada; a chave da intermediária faz as assinaturas do dia a dia e, se vazar, o aval da raiz vaza junto.

Nada disso diz se um site é honesto, embora muita gente entenda o cadeado do navegador justamente assim. Quando o Google estudou a questão em 2021, só 11% dos participantes entendiam corretamente o que o cadeado significava, e quase todos os sites de phishing usavam HTTPS e, portanto, também o exibiam. Em 2023, o Google anunciou que o Chrome trocaria o cadeado por outro ícone. Um certificado básico diz apenas que a conexão vai para quem detém a chave daquele nome. Alguns certificados também identificam a organização por trás do site; nenhum responde por suas intenções.

Há mais uma camada. A Certificate Transparency, proposta por engenheiros do Google em 2013, coloca os certificados em logs públicos nos quais qualquer pessoa pode auditar o que cada AC emitiu. Seus criadores pretendiam que os clientes acabassem recusando qualquer certificado que não tivesse sido registrado, de modo que um certificado mantido fora dos logs, emitido por uma AC ou por um ladrão com a chave de uma AC, fosse recusado. O Chrome faz isso por padrão em toda conexão que depende do seu repositório de confiança.

O alerta que ficou sem resposta

As regras para gerar chaves de AC são rígidas. Para raízes e certas chaves intermediárias, os Baseline Requirements do setor, o regulamento que os programas de certificados raiz dos navegadores e as ACs mantêm em conjunto, determinam que a AC siga um script escrito de geração de chaves e tenha um auditor qualificado como testemunha da cerimônia, ou grave toda ela em vídeo. Qualquer chave de AC deve ser gerada por várias pessoas juntas, nenhuma das quais detenha todo o conhecimento necessário para fazê-lo sozinha.

Em 30 de abril de 2025, a eMudhra criou um lote de 24 intermediárias. Elas se dividiam em três séries, identificadas como A, B e C, com dois tipos de chave, RSA e o tipo de curva elíptica chamado P-384, e quatro finalidades. As oito chaves quebradas eram todas as chaves P-384 das séries B e C. Todas as oito eram números inteiros menores que 256. Escrita por extenso, cada uma era uma longa fileira de zeros com alguma coisa no último byte.

Por que esta chave era adivinhável

Uma chave privada na curva P-384 é simplesmente um número, escolhido ao acaso entre 1 e um limite fixo que, por sua vez, tem 384 bits. A chave pública é calculada a partir da chave privada por uma operação fácil de fazer num sentido e, para um número de fato aleatório, inviável de inverter. Ela vem impressa no certificado. O número 4 é uma chave privada perfeitamente válida; é também um dos primeiros números que qualquer um tentaria. A Mozilla observou que chaves tão pequenas podem ser recuperadas quase instantaneamente: basta calcular as chaves públicas de 1, 2, 3 e assim por diante até 256 e comparar cada uma com a do certificado. Quando duas coincidem, a chave privada é o número de que se partiu. Uma chave de fato aleatória não oferece nenhuma lista curta desse tipo. Como disse Scott Helme, o intervalo contém cerca de 10 elevado a 115 possibilidades, “então ninguém jamais vai vasculhar isso”. Dennis Jackson, da Mozilla, também passou a tarefa a agentes de IA rodando localmente. Eles recuperaram a chave na primeira tentativa, a partir de um prompt simples.

Como uma cerimônia de chaves produziu números tão pequenos? A explicação preliminar da eMudhra, publicada em 19 de outubro, é que o script usado naquele dia tinha uma falha. Segundo a empresa, ela havia aprovado uma alteração pontual no procedimento habitual para testar a exportação das chaves; um erro de programação fez o hardware criar um segundo par de chaves, mais fraco, ao lado dos pares corretos; e as chaves fracas foram depois usadas por engano para solicitar os certificados, porque seus rótulos eram parecidos. A empresa diz que as chaves foram geradas em módulos de segurança de hardware fabricados pela Utimaco, os dispositivos resistentes a violação destinados a produzir e guardar chaves de AC.

A eMudhra chama o relato de preliminar, e ele deixa em aberto o enigma central. Um comentarista do bug público da Mozilla observou que, ou as chaves foram criadas fora do hardware seguro e carregadas nele, contrariando as regras, ou o hardware podia de alguma forma ser configurado para gerar chaves defeituosas por conta própria. Outro participante, na lista de discussão pública da Mozilla, sugeriu, sem confirmação, que um software havia confundido com a própria chave um pequeno arquivo que apontava para a chave verdadeira dentro do hardware. A Mozilla, com muito mais esforço, não conseguiu recuperar as chaves P-384 da série A do mesmo lote. Em 20 de outubro, enviou perguntas à eMudhra com prazo de 24 horas; até 23 de outubro, não tinha recebido resposta, e ninguém havia explicado como as chaves fracas surgiram.

O que está documentado é que o problema já havia dado sinais mais de um ano antes. Em junho de 2025, um serviço público de monitoramento mostrou que a eMudhra servia seis listas de revogação de certificados com assinaturas inválidas para essas mesmas intermediárias. Uma lista de revogação, ou CRL, é um registro assinado dos certificados que uma AC cancelou, e sua assinatura precisa ser validada com a chave pública do certificado da AC. O relatório da eMudhra na época dizia que a Sectigo, outra empresa de certificados, a alertara primeiro por e-mail em 3 de junho de 2025, e que a mensagem havia sido retida em quarentena por filtros internos e não fora vista. As listas defeituosas foram substituídas em 6 de junho.

Em outubro de 2026, a eMudhra explicou em que consistira aquela correção. As listas tinham sido assinadas primeiro com as chaves originais, devidamente aleatórias; como os certificados continham as metades públicas das chaves fracas, essas assinaturas falhavam, e a empresa voltou a assinar as listas com as chaves defeituosas. Em junho de 2025, portanto, a eMudhra tinha indícios de que seus certificados não correspondiam às chaves que achava estar usando, e corrigiu as listas.

O programa de certificados raiz do Chrome perguntou por que a eMudhra simplesmente assinou de novo as listas, em vez de interromper as operações, investigar por que existiam dois pares de chaves para essas ACs e revogar os certificados. A eMudhra diz que suas raízes e ACs emissoras passaram por auditorias independentes dois anos seguidos. Em 14 de outubro de 2026, três dias antes do relato de Wayne, publicou uma lista de revogação de outra raiz, a emSign Root TLS CA – G1, cuja assinatura também não era válida.

Dois tipos de interruptor

O primeiro movimento do Chrome foi rápido porque mirava chaves. O Chrome mantém uma lista de bloqueio chamada CRLSet, que o Google envia aos navegadores em segundo plano. A atualização publicada às 19h45 UTC bloqueou as impressões digitais das chaves públicas das seis intermediárias. Como o bloqueio identificava chaves, abrangia todo certificado que usasse essas chaves, inclusive qualquer um que um falsificador viesse a criar depois. A Mozilla bloqueou os certificados no Firefox por meio de sua própria lista, a OneCRL, e concluiu o trabalho às 22h59 UTC. A OneCRL funciona sem que os usuários precisem atualizar ou mesmo reiniciar o Firefox.

Uma lista enviada em segundo plano só protege o software que a recebe. Em 20 de outubro, a Mozilla lançou uma atualização do Firefox para usuários cujas configurações tinham impedido a chegada da lista de bloqueio e, depois, uma correção para alguns perfis do Firefox para Android que não a aplicavam. O Google começou a enviar um bloqueio equivalente para dispositivos Android pelo Google Play Services por volta das 22h UTC da segunda-feira, 19 de outubro, e disse no dia seguinte que a maioria já o havia recebido. A Microsoft e a Apple fizeram o mesmo em poucos dias, embora os relatos publicados divirjam sobre a data exata da ação da Apple.

As autoridades certificadoras também agiram. A eMudhra marcou os oito certificados como revogados até as 9h38 UTC de 18 de outubro, dando como motivo o comprometimento da AC. A Sectigo, que havia feito a assinatura cruzada das intermediárias, concluiu a revogação de seus certificados cruzados em 19 de outubro. O Chrome também providenciou para que os logs da Certificate Transparency rejeitassem qualquer certificado encadeado às ACs comprometidas, de modo que um certificado forjado já não conseguisse obter as entradas nos logs que os softwares que verificam a CT exigem.

A ferramenta mais pesada é remover a raiz que autorizou as intermediárias. Em 20 de outubro, observando que a essa altura várias pessoas já haviam recuperado as chaves de forma independente, a Mozilla decidiu pela remoção emergencial da emSign ECC Root CA – G3, a raiz da eMudhra acima das intermediárias quebradas, do seu repositório de confiança. O Firefox não precisava disso; a OneCRL já o protegia. A medida era para todos os outros que usam a lista de raízes da Mozilla, ou uma derivada dela, sem a OneCRL. A Mozilla avisou que a mudança tornaria alguns servidores inacessíveis para esses usuários até que os servidores migrassem para novas cadeias de certificados.

O Chrome removeu a mesma raiz do seu repositório. O Google previa que a mudança chegaria a todos os dispositivos que dependem do Chrome Root Store na manhã de terça-feira, 27 de outubro de 2026, no horário do Pacífico, e antes disso nas versões de teste Canary e Beta. O Google disse com todas as letras que, em consequência, alguns certificados legítimos encadeados a essa raiz deixariam de funcionar no Chrome.

Os dois interruptores diferem no que pegam e em quem prejudicam. A remoção de uma raiz corta todos os caminhos que passam por ela, inclusive os de sites honestos, mas deixa escapar os caminhos que passam por outras raízes, e as intermediárias da eMudhra tinham outro. A Sectigo havia feito a certificação cruzada delas, ligando as mesmas chaves a uma raiz chamada AAA Certificate Services, emitida sob o nome Comodo. O Chrome tinha abandonado essa raiz em abril de 2025, mas alguns sistemas ainda confiavam nela: o Ubuntu removeu a emSign ECC Root CA – G3 de todas as suas versões com suporte e, nas versões mais antigas que ainda traziam a raiz da Comodo, removeu também esta. Um bloqueio vinculado à própria intermediária pega todas as rotas de uma vez. A linguagem de programação Go adotou essa abordagem: a partir das versões lançadas em 19 de outubro, o verificador de certificados do Go descarta qualquer cadeia que contenha uma das intermediárias comprometidas, seja qual for a raiz em que termine.

A atualização de todos os outros

Em 18 de outubro, a Mozilla escreveu em seu bug público que estava preocupada com o ecossistema mais amplo, porque muitos endpoints não têm nenhum meio eficaz de receber informações de revogação. Os navegadores tinham suas listas em segundo plano. Muitos outros softwares que fazem conexões seguras não têm nada parecido.

O site de acompanhamento do incidente, uma página pública criada por Dennis Jackson, da Mozilla, detalhou quem estava exposto. Aplicativos e bibliotecas que trazem seu próprio pacote de raízes confiáveis precisavam de atualizações de software. O mesmo valia para os aplicativos feitos com Electron, o framework por trás de programas de desktop como Slack e Discord, que só recebem a correção do Electron quando são recompilados sobre uma versão corrigida.

Algumas brechas estavam nos próprios arquivos de confiança dos sistemas operacionais. Em 22 de outubro, o site do incidente informava que o macOS bloqueava as intermediárias comprometidas, mas que suas ferramentas de linha de comando nativas, incluindo curl, git e python3, verificavam certificados com base em um arquivo separado, sem consultar informações de revogação, e esse arquivo não tinha sido atualizado. No Ubuntu, o repositório de confiança do Java exigia uma ação manual depois da atualização do sistema, por causa de um problema de sincronização que a Canonical não havia resolvido até 22 de outubro, e os navegadores instalados como pacotes snap não usavam de forma alguma o repositório do sistema.

Outras brechas estavam em bibliotecas que carregam suas próprias listas. O Go publicou sua correção nas versões de segurança 1.27.3 e 1.26.10, sob o CVE-2026-111943. O certifi, pacote de raízes muito usado no Python, removeu as quatro raízes emSign em 18 de outubro e depois restaurou as três que não tinham sido afetadas numa versão identificada como 2026.10.19; uma versão automatizada em 23 de outubro voltou a retirar duas dessas três. E alguns produtos só podiam ser corrigidos pelos fabricantes: a equipe de segurança Talos, da Cisco, apontou as redes privadas virtuais como prováveis candidatas a precisar de atualizações.

Por baixo de tudo isso estava a Certificate Transparency. A maioria dos navegadores a exige, mas muitos clientes que não são navegadores, incluindo o curl, não. Um certificado forjado com uma das chaves da eMudhra e nunca registrado seria rejeitado pelo Chrome, mas poderia ser aceito por esses clientes, desde que ainda confiassem na cadeia da eMudhra e nada mais o barrasse, como um aplicativo que aceita apenas os certificados conhecidos dos seus próprios servidores.

Há fortes argumentos de que o sistema funcionou. Nenhum certificado de site encadeado às seis intermediárias foi registrado na Certificate Transparency antes do bloqueio do Chrome em 17 de outubro; assim, entre a criação das chaves, em abril de 2025, e esse bloqueio, nenhum certificado forjado com elas poderia ter sido usado contra clientes que exigem a CT. A Talos disse não ter visto nenhum uso malicioso em ataques reais até as 14h UTC de 21 de outubro. A eMudhra afirma que apenas uma das intermediárias afetadas chegou a entrar em produção e que nenhuma delas jamais emitiu certificado para um site ou para um fabricante de software.

Para os softwares que exigiram a CT o tempo todo, esse argumento está certo, e a proteção veio de uma regra permanente, não da emergência do fim de semana. Seu alcance é mais estreito do que a expressão “o sistema funcionou” sugere. O Firefox para Android só passou a exigir a Certificate Transparency com a versão 145, oferecida aos usuários pela primeira vez em 11 de novembro de 2025. Os aplicativos Android só podem usar verificações de CT nativas a partir do Android 16, e só as recebem por padrão quando compilados para o Android 17.

A emergência também importou para o que veio depois. O primeiro aviso da Mozilla aos mantenedores de repositórios de confiança derivados deliberadamente não dizia que as chaves podiam ser recuperadas por qualquer pessoa. Em 20 de outubro, isso já pouco importava: várias pessoas as haviam recuperado de forma independente, e Helme publicara todos os oito valores. Uma vez que as chaves eram, na prática, públicas, os bloqueios e as rejeições nos logs de CT eram o que se interpunha entre elas e qualquer nova falsificação. Até 24 de outubro, nada do que fora publicado mostrava se atacantes haviam usado as chaves defeituosas contra clientes sem CT entre abril de 2025 e outubro de 2026.

Quem controla o interruptor

As decisões sobre em quais raízes navegadores e sistemas operacionais confiam cabem aos programas de certificados raiz, e as regras desses programas dão a seus donos ampla margem. A política do Chrome diz que o Google inclui ou remove certificados “a seu exclusivo critério” e que cada certificado incluído precisa oferecer aos usuários um valor maior que o risco de mantê-lo. A política da Mozilla diz que ela pode desativar ou remover um certificado a seu exclusivo critério, a qualquer momento e por qualquer motivo. A Mozilla também afirma não cobrar taxas pela inclusão.

Essa discricionariedade tem sido usada de maneiras diferentes. Em 2014, depois que o National Informatics Centre, da Índia, emitiu certificados não autorizados para vários domínios do Google, o Chrome não descartou a raiz India CCA acima dele. Limitou essa raiz a uma lista de domínios indianos. Três anos antes, a resposta a uma autoridade holandesa havia sido total: em 3 de setembro de 2011, o Google decidiu rejeitar todas as autoridades certificadoras operadas pela DigiNotar, e dezessete dias depois um tribunal holandês declarou a falência da empresa.

DigiNotar, 2011

A invasão da DigiNotar veio a público por meio de um usuário comum. Em 28 de agosto de 2011, um cliente da ParsOnline, provedora de internet iraniana, escreveu num fórum de suporte do Google sobre um alerta de certificado que o Chrome lhe havia exibido. O certificado dizia ser do Google e tinha vindo da DigiNotar, cujos sistemas haviam sido invadidos. Investigadores da empresa de segurança Fox-IT, a serviço do governo holandês, concluíram depois que um certificado fraudulento que abrangia endereços google.com tinha sido usado num grande ataque contra aproximadamente 300 mil usuários, quase todos no Irã, cujo tráfego do Google provavelmente foi interceptado ou redirecionado. Eles chegaram a essa estimativa a partir de 298.140 endereços de internet distintos que haviam consultado o status do certificado forjado, e a classificaram como uma aproximação muito grosseira. Em 3 de setembro, o governo holandês revogou publicamente sua confiança na DigiNotar. Nenhum ataque com as chaves da eMudhra havia sido relatado até o fim de outubro de 2026. A DigiNotar mostrou o que o poder de assinatura de uma AC faz nas mãos de alguém disposto a usá-lo.

A inclusão no repositório de confiança do Chrome, escreveu o Google, exige que o dono de uma AC demonstre continuamente a competência técnica e o rigor operacional necessários para proteger os usuários do Chrome, e a empresa disse estar “investigando de perto” se os demais certificados de AC da eMudhra deveriam continuar. Em 23 de outubro, a eMudhra afirmou no bug público que o intenso escrutínio nas redes sociais e as análises de investidores e clientes tinham tornado uma análise significativa do evento “praticamente impossível”. O Chrome respondeu no mesmo dia que isso não era desculpa e que a eMudhra continuava tendo obrigações para com os “bilhões” de pessoas que dependem do sistema e que seu erro expôs.

O conselho de administração da eMudhra já havia decidido, em 22 de outubro, sair do negócio global de certificados SSL/TLS. A empresa diz que esse negócio é uma parcela muito pequena de suas operações.

As mesmas empresas também redigem regras comuns com as ACs num órgão chamado CA/Browser Forum. Numa votação encerrada em 11 de abril de 2025, dezenove dias antes de a eMudhra gerar as chaves defeituosas, Apple, Google, Microsoft e Mozilla votaram todas por encurtar a vida útil dos certificados de sites, e 25 emissores de certificados, entre eles a eMudhra, também votaram a favor. O argumento da proposta era que a revogação não protege adequadamente as pessoas na escala da internet, enquanto a expiração protege. “Os prazos de validade dos certificados, e sua aplicação pelas partes que confiam nos certificados, são incrivelmente confiáveis”, dizia o texto. Pelas regras em vigor em outubro de 2026, certificados de sites emitidos a partir de 15 de março de 2026 podem durar no máximo 200 dias; a partir de 15 de março de 2027, 100 dias; e a partir de 15 de março de 2029, 47 dias.

Esses limites se aplicam aos certificados que os sites usam, conforme a data de emissão. O texto da regra não limita os certificados de AC que estão no centro deste incidente, de modo que prazos mais curtos não teriam feito expirar as intermediárias da eMudhra. Tampouco a revogação desapareceu. A Let’s Encrypt, a autoridade certificadora gratuita, desativou em agosto de 2025 seu serviço OCSP, que permitia aos navegadores consultar um certificado de cada vez, porque cada consulta informava à AC qual site estava sendo visitado a partir de qual endereço de internet. Os bloqueios emergenciais de 17 de outubro foram, na prática, listas de revogação que os próprios fabricantes de navegadores selecionaram e distribuíram.

O arranjo coloca muito poder em poucas mãos privadas, a maioria delas americanas. O que o caso eMudhra mostra é como esse poder é exercido: num bug aberto, em que qualquer pessoa pode ler as perguntas, os prazos e as respostas, com as razões publicadas pelas empresas que fazem a remoção.

Os certificados que precisam migrar

Remover uma raiz é rápido de anunciar e lento de absorver. Em 21 de outubro, o Chrome contava cerca de 30.800 pré-certificados não expirados encadeados à emSign ECC Root CA – G3. Um pré-certificado é a cópia de um certificado enviada aos logs de transparência antes da emissão, de modo que o número conta certificados registrados, não sites que ainda os usam. Desses, 30.791, ou 99,9%, vinham de duas intermediárias pertencentes ao InCommon, serviço de certificados operado pela Internet2, uma organização de redes dos Estados Unidos. Essas duas não estavam entre as oito intermediárias quebradas; apenas estavam penduradas na raiz que seria removida. A eMudhra estimou que cerca de 30 mil certificados precisavam migrar, quase todos emitidos via ACME, o protocolo que permite aos servidores solicitar e renovar certificados automaticamente. A eMudhra parou de emitir sob a raiz G3 em 20 de outubro.

A automação não resolve isso sozinha. Os clientes ACME padrão só substituem um certificado quando chega sua data de renovação, a menos que suportem uma extensão mais recente que permite à AC pedir a renovação antecipada ou que alguém intervenha manualmente. O Chrome observou em 21 de outubro que passar da hierarquia de curva elíptica da eMudhra para a sua hierarquia RSA também pode exigir mudanças nas configurações do cliente.

Os certificados do InCommon vêm pela CertiNext, uma fornecedora cuja controladora é a eMudhra. Em 22 de outubro, o InCommon disse a seus assinantes que muitos deles tinham passado a semana respondendo a erros de certificado e fazendo planos em torno de mudanças fora do seu controle, depois de uma migração bem-sucedida, mas desgastante, ao longo da primavera e do verão americanos. Sua recomendação naquela manhã era reemitir os certificados afetados como RSA até que a emissão em curva elíptica fosse restabelecida.

A eMudhra havia dito em 20 de outubro que a única alternativa para seus clientes da G3 eram intermediárias encadeadas à sua raiz RSA, a emSign Root CA – G1. A Mozilla disse no mesmo dia que não estava retirando a confiança na G1 naquele momento. A G1 estava entre os certificados restantes da eMudhra que o Chrome disse, em 20 de outubro, estar investigando de perto; até 24 de outubro, o Chrome não havia anunciado nenhuma decisão. Em 21 de outubro, o Chrome pediu à eMudhra que confirmasse se os clientes estavam sendo migrados para a G1, para a hierarquia de outra empresa ou para ambas.

A atualização do InCommon da noite de 22 de outubro resolveu o problema imediato. Os certificados de curva elíptica voltavam a ser emitidos, agora encadeados à raiz G1, e os clientes existentes podiam renová-los sem nenhuma mudança nas configurações. A mesma atualização dizia que a eMudhra deixaria de emitir a partir de qualquer intermediária encadeada às suas raízes públicas em 30 dias, numa data a ser confirmada pela CertiNext, e que o InCommon trabalhava num caminho substituto. Para assinantes que haviam concluído uma migração desgastante na primavera e no verão, a remoção de uma única raiz tinha dado início a outra.

Artigos relacionados

• Até onde uma lista de sanções dos EUA alcança um tribunal em Haia
• O que vem a seguir para o Bitcoin?
• Como a IA funciona de verdade: o que os desenvolvedores sabem e as manchetes não contam

Leituras recomendadas

Como Associado da Amazon, a Eikleaf ganha com compras qualificadas. Os links de livros abaixo são links de afiliado: se você comprar por meio deles, podemos receber uma pequena comissão, sem custo adicional para você.

Vídeos recomendados

Aviso sobre IA generativa

Parte do conteúdo desta página foi gerada e/ou editada com a ajuda de uma IA generativa.

Mídia

HTTPS e cadeado na barra de endereços de um site – Wikimedia Commons (Foto: Santeri Viinamäki, CC BY-SA 4.0)

Módulo de segurança de hardware nCipher nShield F3 – Wikimedia Commons (Foto: Alexander Klink, CC BY 3.0)

Sede do Googleplex – Wikimedia Commons (Foto: Asoundd, CC BY-SA 4.0)

Principais fontes e referências

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf