Resumo
- Uma remoção, uma data de desconfiança ou uma versão do navegador muda a política pretendida; não prova que cada sistema, aplicação, contêiner ou equipamento embutido a aplicou.
- A operação deve ser tratada como migração dos sistemas que validam a cadeia, com testes de rejeição para cada fonte de confiança e grupo de clientes.
Em um cenário de validação controlado e hipotético, um grupo atual do Chrome rejeita uma cadeia TLS, enquanto um cliente Windows administrado pela empresa e um serviço dentro de uma imagem antiga de contêiner a aceitam. O certificado é idêntico nos três testes hipotéticos.
Não é uma peculiaridade da sintaxe. É o mapa de três decisões de confiança diferentes.
Em 2024, o Chrome anunciou uma desconfiança direcionada a determinadas raízes da Entrust. A regra dependia da data do primeiro Signed Certificate Timestamp: certificados posteriores ao limite publicado deixariam de ser confiáveis por padrão a partir do Chrome 131, enquanto os anteriores receberiam outro tratamento. Não foi a simples exclusão de um arquivo interpretada ao mesmo tempo por todos os clientes, mas uma regra de aceitação com data efetiva, versão do navegador e espaço para raízes locais explicitamente confiáveis.
A arquitetura do Chrome torna visível o problema da frota. No Windows, macOS, ChromeOS, Linux e Android, o Chrome vem avançando para seu próprio repositório de raízes e mecanismo integrado de validação. No iOS, aplicam-se as regras da plataforma Apple. Uma política empresarial também permitiu temporariamente escolher entre o Chrome Root Store e o mecanismo de validação da plataforma, e o Chrome pode incorporar raízes às quais o sistema operacional atribui confiança explícita. O nome do navegador não identifica toda a fonte de confiança.
A Microsoft mostra uma segunda divergência. Sua documentação distingue Removal, EKU Removal, Disallow, Disable e NotBefore. Retirar uma raiz da lista confiável torna suas cadeias não confiáveis por padrão, mas em certos repositórios ainda é possível instalá-la manualmente. Disallow é mais forte: adiciona o certificado à lista proibida e a instalação manual não recupera simplesmente a confiança. Disable e NotBefore têm regras temporais e de uso próprias.
Esses estados viajam por um sistema de atualização. Clientes Windows conectados podem receber automaticamente as listas confiáveis e proibidas. Um ambiente isolado pode redirecioná-las para um servidor interno. A Microsoft documenta verificações separadas de AuthRoot e Disallowed e do último horário de sincronização. Uma política publicada no servidor não prova que o cliente a consumiu.
A Apple publica um repositório raiz compartilhado e arquiva versões anteriores. A versão instalada torna-se evidência operacional. Também mostra que um dispositivo antigo não é descrito pela lista atual de uma página. A Mozilla igualmente diferencia desativar permissões de confiança e remover o certificado, pode programar qualquer uma das medidas e permite que distribuidores derivados mantenham seleções diferentes.
Defina a ação antes de medi-la
“Remover a raiz” é impreciso demais para comandar um incidente. A intenção pode ser rejeitar todas as cadeias, apenas certificados emitidos depois de uma data, um uso específico ou uma raiz dentro de um programa de certificados raiz, preservando uma exceção privada. Cada ação exige um resultado de teste diferente.
O denominador não são dispositivos cadastrados, mas grupos de sistemas de validação: navegador e versão, repositório do sistema, ambiente de execução, repositório de certificados do runtime, imagem-base, firmware, cliente embutido e exceção administrada. Para cada grupo, preserve a impressão digital da raiz, a cadeia observada e se o resultado esperado é aceitação ou rejeição. Um cliente obsoleto que ainda conecta após uma medida de segurança está falhando, mesmo que o monitor de disponibilidade continue verde.
Documentos públicos estabelecem políticas e mecanismos de distribuição. Não revelam inventário, exceções, ciclos de firmware nem resultados de um operador. A conclusão operacional é uma inferência: a mudança de confiança deve ser confrontada com os sistemas que validam o processo real. Ela não atribui interrupção a qualquer cliente, operador de raiz ou plataforma.
Fontes
- https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html
- https://www.chromium.org/Home/chromium-security/root-ca-policy/
- https://support.google.com/chrome/a/answer/2657289
- https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
- https://learn.microsoft.com/en-us/security/trusted-root/deprecation
- https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates
- https://support.apple.com/en-us/103272
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

