--- title: "Chrome bloqueia certificados após sequestros de domínios de países" author: "Ignácio Afonso" date: "2026-10-07 07:45:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/10/07/chrome-bloqueia-certificados-apos-sequestros-de-dominios-de-paises/md" --- ## Resumo - Três registros ccTLD, .gh, .sl e .as, foram comprometidos na semana anterior a 6 de outubro de 2026. - Os invasores alteraram registros DNS autoritativos e passaram pela validação de controle de domínio para obter certificados HTTPS válidos. - O Google afirmou que seus próprios sistemas não foram comprometidos e não encontrou indícios de irregularidades por parte das autoridades certificadoras. - O Chrome bloqueou os certificados identificados por meio de CRLSets e o Google coordenou a revogação com as CAs. - Logs de Transparência de Certificados ajudaram a identificar outras organizações e serviços afetados. - Administradores devem monitorar logs de CT e configurar registros CAA mais restritivos. - A resposta de longo prazo inclui reduzir a validade dos certificados e limitar a reutilização de validações DCV. --- Na **semana anterior a 6 de outubro de 2026**, três registros de domínios de código de país foram comprometidos, permitindo que invasores alterassem o DNS e conseguissem certificados HTTPS válidos para domínios do Google e de outras organizações. O caso envolveu os registros **.gh, .sl e .as**, associados a Gana, Serra Leoa e Samoa Americana. A resposta veio em duas frentes: o Chrome bloqueou os certificados identificados por meio de CRLSets, enquanto o Google trabalhou com autoridades certificadoras para revogá-los. O ponto mais importante para quem navega é entender o limite dessa proteção: o bloqueio no navegador reduz o risco conhecido, mas não corrige sozinho a infraestrutura dos registros comprometidos nem garante proteção completa em outros navegadores. ## O ataque começou na camada que traduz domínios em endereços Para entender por que certificados legítimos puderam ser obtidos, é preciso acompanhar a sequência técnica descrita pelas fontes. Os invasores comprometeram as infraestruturas de terceiros responsáveis pelos registros **ccTLD**, sigla usada para domínios de primeiro nível associados a códigos territoriais, e alteraram os registros DNS autoritativos. O DNS, sistema que direciona um nome de domínio para os endereços usados na internet, passou a ser a peça manipulada no processo. A partir desse controle, os invasores conseguiram passar pela **validação de controle de domínio**, conhecida pela sigla DCV, uma verificação usada pelas autoridades certificadoras para confirmar o controle sobre um domínio. A cadeia de confiança foi explorada antes que o navegador pudesse reagir, e é justamente essa ordem dos acontecimentos que explica a urgência da resposta. Esse caminho permitiu a emissão de certificados de segurança reconhecidos como válidos, embora não autorizados pelos responsáveis legítimos pelos domínios afetados. Segundo a cobertura especializada, os certificados poderiam fazer com que conexões de sites falsificados passassem pela verificação de segurança apresentada ao usuário. O Google informou que **seus próprios sistemas não foram comprometidos** e que não havia indícios de irregularidades por parte das autoridades certificadoras, porque elas receberam respostas que atendiam ao processo de validação disponível naquele momento. A empresa também não divulgou a quantidade de certificados emitidos, a identidade dos invasores ou o método exato usado para comprometer os registros, mantendo esses pontos em aberto enquanto a resposta técnica avançava. ## Como o Chrome identificou e bloqueou os certificados Como a emissão poderia atingir organizações além das propriedades do Google, a equipe recorreu aos logs de **Transparência de Certificados**, conhecidos como CT. Esses registros públicos permitem observar certificados emitidos e ajudaram o Google a identificar outras marcas e serviços online potencialmente afetados, além de suas próprias propriedades. A empresa usou essas informações para localizar certificados associados ao incidente e tentou contatar as organizações atingidas. No navegador, a contenção ocorreu por meio dos **CRLSets**, mecanismo usado pelo Chrome para bloquear certificados identificados como comprometidos. A medida mostra por que a visibilidade sobre a emissão de certificados é tão relevante: sem os logs, certificados obtidos por uma alteração temporária no DNS poderiam permanecer menos visíveis para as equipes responsáveis pela defesa. Depois desse bloqueio no Chrome, o Google coordenou a revogação dos certificados com as **autoridades certificadoras**, também chamadas de CAs, para ampliar a proteção a usuários de outros navegadores. Revogar um certificado significa retirá-lo da condição de confiança concedida durante sua emissão, mas o alcance prático dessa ação depende da forma como cada navegador e sistema consulta ou aplica informações de revogação. A análise publicada pela [Help Net Security](https://www.helpnetsecurity.com/2026/10/07/google-unauthorized-https-certificates-cctld-hijacks/) reforça que a intervenção do Chrome não garante proteção completa para todas as pessoas que usam outros navegadores. Por isso, o bloqueio deve ser entendido como uma contenção direcionada aos certificados identificados, e não como a confirmação de que todos os riscos ligados aos registros desapareceram. ## O que os administradores devem fazer depois do bloqueio Depois da restauração do controle sobre o DNS, a recomendação passa a depender também dos administradores dos domínios. As fontes orientam o acompanhamento contínuo dos logs de **Transparência de Certificados** para detectar novas emissões que não tenham sido autorizadas pelas organizações responsáveis. A segunda medida é implementar registros **CAA**, sigla para Certification Authority Authorization, com regras mais restritivas. Esses registros servem para declarar quais autoridades certificadoras estão autorizadas a emitir certificados para um domínio, e a orientação é usá-los como uma camada adicional para mitigar riscos depois que o controle DNS for recuperado. A lógica é direta: identificar rapidamente uma emissão suspeita e limitar, por configuração, as autoridades que podem participar desse processo. Além da resposta imediata, o Google relacionou o incidente a mudanças de longo prazo na emissão de certificados HTTPS. A empresa reforçou iniciativas voltadas à **redução do período de validade dos certificados** e à limitação da reutilização de validações de controle de domínio, conhecidas como DCV. Quanto menor o tempo de validade, menor tende a ser a janela associada a um certificado comprometido, embora a fonte não apresente uma eliminação completa do risco. Esses trabalhos são conduzidos por meio do **Chrome Root Program** e do novo Chrome Quantum-resistant Root Program. A referência a esses programas mostra que a resposta não termina na lista de bloqueio do navegador, pois também envolve mudanças nos processos que sustentam a confiança das conexões HTTPS. ## O que muda agora para usuários e organizações Para quem usa o Chrome, os certificados identificados no incidente foram bloqueados pelo navegador, o que reduz a possibilidade de confiar em conexões associadas a esses certificados específicos. A ação, porém, não significa que o comprometimento dos registros tenha sido revertido pelo navegador ou que todos os certificados relacionados tenham sido automaticamente neutralizados em qualquer ambiente. O Google afirmou que trabalhou para revogar os certificados com as CAs e que usou os logs de CT para encontrar organizações afetadas além de suas próprias propriedades. A [explicação publicada pelo Google](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks) ajuda a separar duas etapas diferentes: o Chrome bloqueia o que conseguiu identificar, enquanto a correção mais ampla depende da recuperação do controle dos registros e da atuação dos responsáveis pela emissão. O próximo passo concreto para administradores é acompanhar os logs de CT e revisar os registros CAA, adotando autorizações mais restritivas para novas emissões de certificados. Para usuários, manter o navegador atualizado e observar alertas de conexão continua sendo a proteção disponível dentro do navegador, mas o incidente deixa uma lição mais ampla sobre a web: o cadeado HTTPS depende de uma cadeia que começa no controle do domínio e passa pela validação das autoridades certificadoras. O Chrome conseguiu bloquear os certificados identificados, e a revogação coordenada amplia a defesa em outros navegadores, mas a segurança só avança quando a infraestrutura dos registros, as configurações dos domínios e os processos de emissão são corrigidos em conjunto.