Resumo

  • A Let's Encrypt informou em 29 de fevereiro de 2020 que o Boulder, seu software de autoridade certificadora, tinha um erro na reverificação de registros DNS CAA para solicitações com vários nomes [1].
  • O RFC 8659 define CAA como um registro de recurso DNS que permite ao titular do domínio especificar quais autoridades certificadoras podem emitir certificados para esse domínio [2].
  • A questão de responsabilidade não era o suporte geral da Let's Encrypt a CAA. Era se cada nome coberto por uma validação reutilizada recebeu uma verificação recente antes da emissão [1].
  • A página oficial da Let's Encrypt descreve o serviço como uma autoridade certificadora fornecida pelo Internet Security Research Group. O vínculo de diretório BTW usa internet-society, sem mudar o sujeito factual do incidente [3].

O que aconteceu

O aviso da Let's Encrypt descreve uma falha descoberta em 29 de fevereiro de 2020 no Boulder. O Boulder normalmente verifica registros CAA quando valida o controle de um assinante sobre um domínio. Como algumas validações continuam utilizáveis por um período depois da primeira verificação, a autoridade pode precisar verificar CAA novamente antes de emitir. A Let's Encrypt disse que a regra aplicável exigia verificação CAA nas oito horas anteriores à emissão quando a validação era mais antiga [1].

O modo de falha era específico. Quando uma solicitação de certificado continha vários nomes que precisavam de reverificação CAA, o Boulder escolhia um nome e o verificava várias vezes, em vez de verificar cada nome relevante. Assim, uma solicitação podia passar mesmo que um ou mais nomes não tivessem recebido a verificação DNS recente esperada. A Let's Encrypt afirmou que confirmou o erro às 03:08 UTC, interrompeu a emissão às 03:10 UTC, implantou uma correção às 05:22 UTC e depois reativou a emissão [1].

Essa linha do tempo importa porque a responsabilidade de uma autoridade certificadora não é comprovada apenas dizendo que o código foi corrigido. O sistema também precisava identificar certificados potencialmente afetados, notificar assinantes, permitir substituição e executar revogação. O registro público, portanto, incluiu identificação do defeito, correção do caminho de emissão e limpeza do ciclo de vida dos certificados [1].

Por que CAA é um controle DNS

O RFC 8659 apresenta CAA como um registro DNS pelo qual o titular de um domínio especifica autoridades autorizadas. O padrão também descreve CAA como um controle adicional para reduzir o risco de emissão não intencional [2]. CAA é, portanto, uma fronteira entre o estado DNS publicado pelo operador do domínio e a decisão de emissão da autoridade.

Para risco e responsabilidade, o ponto não é a marca do certificado. É a cadeia de autoridade operacional: o proprietário publica CAA, a infraestrutura DNS retorna o estado visto pela CA, o software interpreta esse estado e a automação do assinante espera renovação em escala. Se essas etapas viram apenas “validação aprovada”, a fronteira de evidência fica fraca demais.

Limite do diretório

O sujeito direto é a Let's Encrypt e o serviço ISRG descrito pelas fontes oficiais. O vínculo entity:internet-society é usado porque a entidade existe em produção e já foi usada em cobertura anterior de confiança de certificados da Let's Encrypt. Isso não afirma que a Internet Society tomou a decisão de engenharia no Boulder. Se um gate de proprietário exigir entidade ISRG direta, o candidato deve parar com precisão antes de publicar.

Evidências necessárias

Um fechamento defensável deve mostrar quais nomes exigiam nova verificação CAA, quais respostas DNS foram usadas, qual caminho de software tomou a decisão, quais certificados entraram no escopo, como os assinantes foram notificados e como a recorrência foi testada. Sem isso, o reparo fica como uma afirmação privada em uma cadeia pública de confiança.

Fontes

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/