Resumo

  • A aquisição pela DigiCert transferiu uma atividade comercial e criou uma rota para nova infraestrutura de emissão. Google, Mozilla e Apple, porém, continuaram decidindo em seus próprios clientes quando e como deixar de confiar na PKI legada da Symantec.
  • Continuidade em PKI pública depende de uma relação revogável no lado de quem confia. Certificado válido, assinatura correta e compra concluída são evidências relevantes, mas não obrigam o próximo cliente a aceitar a cadeia.

O ativo que não constava do contrato

Uma venda empresarial pode transferir funcionários, clientes, sistemas, obrigações e receita. Em 2017, também podia financiar uma infraestrutura de emissão operada independentemente pela DigiCert. A eficácia de uma raiz pública, contudo, vinha de softwares de terceiros que a tratavam como âncora de confiança. A decisão futura desses softwares não pertencia à Symantec para ser entregue.

A Mozilla formulou essa fronteira diretamente: confiança de um programa de raízes não se transfere automaticamente entre organizações. A aquisição não cancelaria a retirada planejada. Se cancelasse, uma autoridade submetida a sanção poderia escapar por reestruturação ou venda e continuar, sob outro nome, uma operação essencialmente igual.

O registro do Google mostra a razão da perda de confiança. Uma publicação de janeiro de 2017 chamou atenção para certificados questionáveis de autenticação de sites. A investigação apontou organizações com poder de emissão sem supervisão adequada e inseriu o caso num padrão de problemas. A equipe do Chrome perdeu confiança na infraestrutura antiga.

Não era uma acusação de fraude contra cada certificado. Era a retirada de uma presunção ampla sobre a hierarquia. Por isso a resposta separou infraestrutura nova e antiga, ofereceu período de substituição e alterou gradualmente as cadeias aceitas pelos clientes.

Quatro relógios sem um corte mundial

O primeiro relógio era a emissão. O plano do Chrome usou 1º de junho de 2016 como limite para a fase do Chrome 66. O dia 1º de dezembro de 2017 marcou a transição para a infraestrutura administrada pela DigiCert; emissões posteriores pela infraestrutura antiga não seriam aceitas. O Chrome 70 retiraria de forma mais ampla a confiança no legado, salvo exceções restritas.

O segundo relógio era o lançamento do software. Canary, Beta e Stable transformaram o anúncio em comportamento progressivo. O Google também permitiu que empresas desativassem temporariamente a desconfiança, mas encerrou essa política em 1º de janeiro de 2019. Era uma pausa local, não restauração pública da confiança.

A Mozilla seguiu outra cadência. O Firefox 58 avisou no console; o Firefox 60 passou a rejeitar certificados afetados emitidos antes de 1º de junho de 2016; uma fase posterior removeria as raízes antigas, com poucas exceções subordinadas. Como muitos sites ainda não tinham migrado, a Mozilla adiou a etapa final do Firefox 63 para o 64. A decisão equilibrava exposição adicional e indisponibilidade em massa.

O terceiro relógio pertencia ao site. Um certificado podia estar longe do vencimento e deixar de funcionar antes. A Mozilla estimou que cerca de 1% do milhão de sites mais acessados ainda seria afetado no começo de março de 2018; pouco antes do Firefox 60, a parcela havia caído para menos de 0,15%. Em outra medição para a fase seguinte, 3,5% ainda usava certificados a serem recusados. São recortes de telemetria, não um censo global, mas revelam o volume de inventário e substituição acionado pela política.

O quarto relógio era a base instalada. A Apple começou a desconfiança parcial em 1º de agosto de 2018 e manteve uma janela limitada quando o certificado aparecia em log CT confiável. A empresa registra 25 de fevereiro de 2020 como início da desconfiança completa nas autoridades listadas. Chrome, Firefox e plataformas Apple não compartilharam um único interruptor.

Assim, o mesmo certificado podia autenticar um site para uma pessoa e falhar para outra. Os bytes eram iguais; o estado local de confiança era diferente.

Transparência não era absolvição

O RFC 6962 define Certificate Transparency por logs somente anexáveis, carimbos de tempo assinados e provas de consistência. Titulares podem descobrir emissões inesperadas e auditores podem provar que um log mostrou histórias incompatíveis.

O texto também limita a conclusão: um carimbo assinado não garante que o certificado tenha sido emitido corretamente. CT torna a emissão observável. Não prova o direito do solicitante, a qualidade da validação nem uma obrigação do navegador de continuar confiando no emissor.

A regra transitória da Apple usou inclusão em log como uma condição durante uma janela delimitada. Não concedeu legitimidade permanente à raiz. Para a empresa, encontrar um certificado inesperado em CT deve abrir investigação sobre solicitante, validação, implantação, população cliente e revogação.

A autoridade eficaz estava no cliente

Uma raiz parece autoridade central, mas só ganha força quando clientes executam a regra de aceitá-la. Google podia mudar o Chrome; Mozilla, o Firefox; Apple, seus sistemas; empresas podiam conservar exceções temporárias; sites podiam servir outra cadeia. Cada participante tinha poder decisivo dentro de um limite, sem apagar escolhas alheias.

A primazia do código em execução, exposta por Heng Lu, entra aqui como lente declarada, não como prova do episódio. Uma pretensão institucional ganha efeito quando sistemas usados pelos participantes a aplicam; dependência técnica tampouco deveria virar soberania ilimitada. A venda da Symantec não reescreveu os repositórios de confiança. A nova operação precisava oferecer uma cadeia que as partes dependentes ainda escolhessem aceitar.

Isso não torna neutro o poder dos navegadores. Poucos fornecedores podiam impor custo mundial de migração. Critérios publicados, evidências, implantação por etapas, exceções com prazo e coerência entre casos são necessários. Conseguir executar uma decisão não prova que ela foi justa.

Do calendário de expiração ao mapa de dependência

Inventário baseado apenas em vencimento falha nesse cenário. O registro útil contém cadeia completa, famílias de raízes, programas usados pelos clientes relevantes, canais de versão, datas de emissão, requisitos CT, exceções subordinadas e prova de funcionamento da substituição em clientes reais.

Comprometimento de chave, emissão incorreta, falha de auditoria, revogação de folha, desconfiança de raiz e distribuição de navegador também precisam ficar separados. Podem interagir, mas possuem donos e mecanismos de impacto diferentes.

Na aquisição de uma CA, diligência deve separar contratos, capacidade atual, raízes antigas e novas, relações subordinadas, auditorias, participação em CT e custo de trocar o estoque implantado. Receita presa a uma cadeia com data de retirada não equivale à receita já migrada.

Limites da evidência

As fontes oficiais sustentam os cronogramas e a não transferência automática. Não mostram que todo certificado legado era indevido. As porcentagens da Mozilla são medições pontuais. A data da Apple não substitui as datas do Chrome ou Firefox. Um programa de raízes exerce autoridade eficaz sobre seus clientes, não soberania universal sobre a Web.

Fontes