Radar Tech: as chaves de uma autoridade certificadora vazaram do próprio certificado — e a frota que não lê revogação continua confiando

O que aconteceu

A página de acompanhamento de um incidente de CA, publicada ontem e no topo das discussões técnicas, descreve um caso raro e didático: as chaves privadas de oito certificados de CA intermediária de uma autoridade comercial foram geradas de forma incorreta — recuperáveis a partir do próprio certificado. Não houve invasão de servidor nem cópia de arquivo. O segredo nasceu público.

A consequência é direta: quem tem a chave de uma intermediate pode assinar certificado "válido" para qualquer domínio, porque a cadeia termina em uma raiz que praticamente todo cliente confia. A página demonstra isso do jeito mais honesto possível — assinando uma mensagem com cada uma das oito chaves.

As intermediates foram emitidas em abril do ano anterior. Não há entradas em logs de Certificate Transparency para elas nesse período, o que significa que clientes que exigem CT — os navegadores modernos — não poderiam ter sido atacados por esse caminho. Para todo o resto, a frase da própria página é a mais importante do texto: não se sabe se a geração falha foi explorada.

Quem já bloqueou e quem não

Os root programs agiram em dias: a CA foi bloqueada nos mecanismos de distribuição de navegadores a partir do dia 17, em dispositivos Apple no dia 19 e em plataformas Microsoft no dia 20. Para quem usa navegador atualizado, o problema está resolvido.

O problema real começa depois do navegador. A página lista, em uma tabela pública, quais pacotes já corrigiram o bundle — distribuições Linux, Homebrew, Alpine, runtimes, bibliotecas de CA. E lista também o que está pendente. Essa tabela é, na prática, um mapa da assimetria que todo arquiteto deveria conhecer: o navegador atualiza junto com o fornecedor do sistema; o container atualiza quando alguém reconstrói a imagem; o appliance atualiza quando o fabricante publica firmware.

Por que isso é um problema de distribuição, não de configuração

O mesmo alerta gera três respostas que parecem equivalentes e não são:

• "Atualizamos os servidores." Talvez. O host pode estar com o pacote novo e a sua aplicação continuar lendo um bundle próprio: cacerts do JRE dentro da imagem, bundle do Node embutido no runtime, certifi empacotado na wheel, ca-bundle duplicado em node_modules.
• "O navegador já bloqueia." Bloquear na ponta do usuário não diz nada sobre o cliente que a sua API usa para falar com um parceiro.
• "A CA revogou." Revogação só vale para quem consulta. Muitos clientes com bundle estático, SDKs de dispositivo e firmwares simplesmente não consultam CRL nem OCSP.

E há o efeito colateral que aparece no primeiro bloqueio mal planejado: um parceiro legítimo que ainda usa certificado emitido por aquela CA para de validar. Bloquear é uma decisão com duas pontas.

O que fazer esta semana

• Inventarie, por segmento de cliente, onde mora o bundle e qual é a data dele. Versão do SO não descreve imagem de container.
• Dê a cada segmento um status verificável: atualizado, pendente, sem caminho ou desconhecido. "Acho que está atualizado" é desconhecido.
• Meça a idade do bundle como métrica. É o único número que antecipa o próximo incidente.
• Trate o appliance de campo como um item de contrato, não de operação: sem firmware do fornecedor, o caminho é bloquear a CA na saída da rede e registrar o risco residual.
• Nunca resolva desligando validação de TLS. Isso troca um risco de impersonação por um MITM permanente — e passa a ser o problema principal.

A leitura de arquitetura

Confiança de CA não é configuração de servidor: é um artefato versionado que se distribui por um caminho — pacote, imagem, runtime, firmware — com latência diferente em cada um. Quem não versiona esse caminho descobre o atraso no dia do incidente, com o relógio do atacante correndo.

É exatamente essa a decisão que o prompt publicado hoje no catálogo (ADR, matriz de exposição e plano de atualização de trust store) ajuda a registrar por escrito.