Resumo

  • Uma validação DNS-01 bem-sucedida prova que certa conta ACME possui sua chave privada e consegue fazer o digest exigido aparecer no nome de validação observado pela autoridade certificadora. Uma delegação CNAME ou NS pode entregar esse poder estreito sem entregar a zona apex, o aplicativo ou o mandato empresarial.
  • Pedido, autorização, escopo curinga, CSR, emissão, custódia da chave, implantação, observação em CT e revogação são estados diferentes. Apagar o TXT ou o acesso de um fornecedor não encerra todos eles.

O desligamento que não chegou ao DNS

A empresa fez o que parecia suficiente: bloqueou o SSO do fornecedor, removeu seu segredo da CI e retirou sua função no armazenamento de certificados. O inventário de aplicações não mostrava integração ativa. Porém, o pai de DNS ainda encaminhava _acme-challenge.example para uma zona controlada pelo antigo prestador.

Essa delegação tinha efeito operacional. A documentação da Let's Encrypt informa que sua consulta DNS-01 pode seguir CNAME ou NS até outra zona. Uma parte que conserva a chave da conta ACME e controla a resposta final pode receber um novo desafio, calcular o valor correto e obter uma emissão curinga sem tocar nos servidores web.

O cenário é sintético; não atribui um incidente a uma empresa ou CA específica. Ele separa duas perguntas que os inventários costumam fundir: quem acessa a aplicação e quem ainda controla uma capacidade de emissão gravada no DNS.

O que o digest demonstra

No RFC 8555, o TXT não é uma senha estática. O servidor ACME fornece um token com pelo menos 128 bits de entropia. O cliente o combina com a chave da conta para formar a key authorization, calcula SHA-256 e publica o digest em base64url em _acme-challenge.<identificador>.

Duas condições se encontram: a parte consegue assinar como a conta ACME e consegue tornar visível o valor previsto no nome de validação. Se a chave ou o token mudar, muda também o digest. Reutilizar uma resposta antiga não equivale a provar uma nova ordem.

Uma authorization é a decisão do servidor de permitir que uma conta represente um identificador. O estado válido possui expiração e pode depois expirar, ser desativado ou revogado. Por isso, um registro de auditoria útil não diz apenas “domínio validado”. Ele identifica conta, authorization, identificador, método, observação e janela de validade.

Uma superfície pequena ainda pode emitir

Separar o serviço de validação pode reduzir risco. É preferível dar a ele uma zona dedicada ou credencial restrita a instalar no aplicativo uma chave capaz de editar todo o DNS. Mas a delegação sobrevivente continua sendo uma capacidade real.

O controle precisa registrar todos os saltos CNAME e NS, a conta que administra a zona final, o estado DNSSEC, TTL e respostas vistas de pontos relevantes. DNSSEC pode autenticar perfeitamente a delegação e os dados; não consegue concluir se o contrato do fornecedor continua autorizado. Uma captura do painel da zona pai também não prova o caminho efetivamente consultado.

Propagação e cache criam tempos diferentes para a alteração autoritativa, as respostas recursivas e a observação da CA. Um teste de remoção deve atravessar o TTL e comparar vistas, em vez de declarar sucesso assim que o painel salva a mudança.

O curinga está no escopo, não no rótulo TXT

Em um pedido curinga, o RFC 8555 devolve uma authorization para o domínio base, sem *., e marca wildcard: true. O nome _acme-challenge.example pode parecer comum enquanto o certificado solicitado cobre um conjunto muito mais amplo. O sinalizador deve permanecer junto do pedido e do CSR.

A Let's Encrypt descreve DNS-01 como o caminho para seus certificados curinga. Isso documenta o comportamento atual dessa CA, não uma regra universal de todos os servidores ACME. O RFC 9444 também define um mecanismo opcional no qual a política do servidor pode aceitar autorização de um domínio ancestral para subdomínios. A implementação precisa ser comprovada; o auditor deve guardar o identificador que o servidor realmente autorizou.

O CSR limita nomes, não o mandato

Os identificadores de uma ordem ACME são imutáveis. Na finalização, o CSR deve conter exatamente o mesmo conjunto. Não se pode acrescentar um SAN oportunista depois da validação. Essa regra fecha uma porta específica.

Ela não determina quem deveria guardar a chave privada, onde o certificado pode ser instalado nem qual função de aplicação ele pode liberar. Ordem, authorization, CSR, emissão, armazenamento, implantação e primeiro handshake observado precisam ser eventos separados, cada qual com dono e horário.

CAA pode estreitar outra parte da superfície. O RFC 8657 define parâmetros opcionais accounturi e validationmethods para issue e issuewild. Eles só produzem o efeito esperado quando a CA indicada os reconhece de modo consistente, e não substituem a validação do domínio. O próprio RFC alerta que delegar o controle de um subdomínio pode superar restrições CAA. A política não dispensa a remoção da delegação.

Limpeza de DNS não é revogação

Apagar um TXT encerra uma resposta. Remover um CNAME ou NS encerra uma rota depois da convergência dos caches. Desativar uma authorization ou conta ACME muda outro estado. Nenhum desses atos revoga, sozinho, um certificado que já foi emitido.

O ACME prevê uma solicitação de revogação assinada. A conta emissora, uma conta autorizada para todos os identificadores do certificado ou a própria chave privada do certificado podem fornecer autoridade protocolar para revogar. OCSP e CRL expõem outra superfície de estado, cujo tempo de observação pelos clientes também importa.

Certificate Transparency torna emissões observáveis e auditáveis. Um SCT, porém, não é a validação normal do certificado, e a inclusão no log não o invalida. O alerta de CT precisa acionar investigação e revogação, não ser confundido com a resposta final.

Faça cada fronteira falhar

Um painel verde de renovação é menos esclarecedor do que testes negativos. Retire o acesso à aplicação e mantenha a delegação para verificar se uma nova ordem ainda passa. Troque a chave da conta e publique o digest derivado da chave antiga. Acrescente ao CSR um SAN ausente da ordem. Valide simultaneamente um nome exato e um curinga. Remova a delegação e observe servidores autoritativos e caches antes e depois do TTL.

Depois, emita sem implantar, apague o desafio e confirme que o estado do certificado não mudou por mágica. Cada controle deve falhar precisamente na fronteira que afirma proteger.