Registro CAA: a cadeia de CNAME pode bloquear a emissão do certificado

Para restringir quais autoridades certificadoras podem emitir para um domínio, levante primeiro todos os serviços que emitem ou renovam seus certificados. Consulte então os registros CAA do nome solicitado, dos seus nomes pais e dos destinos de eventuais CNAMEs. Pela regra de consulta da RFC 8659, a autoridade segue aliases na resolução DNS e procura um conjunto CAA aplicável antes de emitir. Uma restrição encontrada no destino pode, portanto, bloquear o pedido.

Faça a configuração em duas fases: inventarie emissores e políticas existentes; depois publique somente as permissões necessárias e teste a emissão pelos serviços responsáveis pela renovação. Um certificado já instalado não demonstra, por si só, que a próxima solicitação continuará autorizada: o CAA é verificado no momento de uma nova emissão.

Inventarie os certificados e as autoridades

Liste cada nome que aparece nos certificados do site, dos subdomínios e dos serviços associados. Inclua certificados curinga e, quando houver, os certificados apresentados na borda de uma plataforma e os instalados no servidor de origem. Para cada grupo, registre quem solicita o certificado, qual autoridade pode emiti-lo e qual sistema fará a renovação.

O emissor exibido no certificado atual ajuda a começar o levantamento, mas serviços que administram certificados podem trocar de autoridade em emissões futuras. Confirme com cada fornecedor os valores CAA exigidos para sua modalidade de serviço, inclusive quando ele escolhe a autoridade automaticamente. Essa consulta evita montar a política apenas para o certificado mais visível e descobrir a omissão durante uma renovação.

Encontre a política aplicada a cada nome

Consulte CAA para o nome exato que entrará no certificado. Se não houver conjunto CAA ali, examine seus nomes pais até encontrar o primeiro conjunto aplicável. Num exemplo hipotético, um pedido para loja.exemplo.com pode usar um CAA publicado em exemplo.com; se loja.exemplo.com tiver seu próprio conjunto, é esse conjunto que vale, mesmo quando é mais permissivo que o do pai.

Se o nome solicitado for um CNAME, anote os destinos sucessivos da cadeia e consulte CAA também nesses nomes. Com dig, comece por dig loja.exemplo.com CNAME e dig loja.exemplo.com CAA, repetindo a consulta CAA para os destinos encontrados. A busca pelos nomes pais parte do nome solicitado no certificado; a regra atual não manda repetir essa subida por todos os nomes pais de cada destino CNAME. Ainda assim, um CAA devolvido na resolução do alias pode ser o conjunto decisivo.

Não dependa apenas do painel da zona que você administra. Um alias pode terminar em outra zona, controlada pelo serviço de hospedagem, cuja política não aparece no seu painel. Consulte a resposta DNS completa: a opção +short ajuda a enxergar os valores, mas pode ocultar o status necessário para distinguir uma resposta vazia de uma falha de consulta. Se o destino impuser uma autoridade diferente, confirme com o responsável por aquela zona onde a permissão precisa ser ajustada.

Publique issue e trate curingas separadamente

No provedor DNS, crie uma entrada CAA para cada autoridade necessária no nível em que a política deve começar a valer. O formato apresentado pela especificação reúne o nome, o tipo CAA, a flag, a propriedade e o valor. Num exemplo puramente hipotético, exemplo.com CAA 0 issue "ca.exemplo.net" permitiria à autoridade identificada por ca.exemplo.net emitir certificados comuns sujeitos àquele conjunto. Use o identificador informado pela autoridade real, não o nome comercial presumido.

Para certificados curinga, verifique issuewild antes de publicar. Quando o conjunto aplicável contém ao menos uma entrada issuewild, as entradas issue deixam de autorizar pedidos curinga; para nomes comuns, issuewild é ignorada. Sem issuewild, as permissões issue também podem valer para curingas. Assim, uma política que precisa separar os dois casos deve incluir explicitamente as autoridades corretas em cada propriedade.

Um nome que possui CNAME não pode ter um CAA no mesmo ponto do DNS. Se a restrição vier do destino do alias, acrescentar uma entrada no nome de origem não resolve essa impossibilidade. A alteração pode depender da zona de destino, de uma configuração oferecida pelo fornecedor ou da escolha de outro alias. Confira o conjunto efetivamente aplicado antes de editar o domínio pai.

Considere as entradas automáticas da Cloudflare

A documentação de CAA da Cloudflare informa que, com Universal SSL ativo, a plataforma acrescenta permissões automaticamente quando há registros CAA na zona. Essas entradas podem aparecer numa consulta com dig sem constar no painel. O mecanismo descrito para Universal SSL não se aplica da mesma forma aos certificados do Advanced Certificate Manager.

Por isso, compare a resposta pública do DNS com as entradas que você criou e com as autoridades necessárias aos certificados administrados pelo serviço. A lista de autoridades incluídas automaticamente pode mudar por razões operacionais; não a trate como uma lista fixa a ser copiada. Se um subdomínio usa uma zona própria e o domínio pai fica em outro provedor, inclua também o CAA desse pai na consulta.

Teste a emissão antes de depender da renovação

Depois de publicar, repita as consultas para todos os nomes inventariados e solicite certificados de teste pelos mesmos serviços que farão as renovações. A orientação da Let’s Encrypt identifica letsencrypt.org como seu valor CAA, explica que sua validação segue CNAMEs e recomenda usar o ambiente de testes para investigar erros de CAA. Erros de DNS podem impedir que a autoridade determine se a emissão está autorizada.

Teste separadamente os nomes comuns e os curingas que a configuração precisa atender. Se um pedido falhar, identifique a autoridade usada naquele pedido, o conjunto CAA encontrado para o nome, a propriedade issue ou issuewild pertinente e cada destino do CNAME. Uma resposta DNS vazia e uma falha como SERVFAIL exigem diagnósticos diferentes: na segunda situação, acrescentar outra permissão pode deixar o problema de resolução intacto.

Registre os nomes testados e as autoridades esperadas junto da configuração DNS. Quando mudar o serviço de certificados, o destino de um CNAME ou a política de uma zona pai, repita as consultas e os pedidos de teste antes da próxima renovação automática.

Leia também:

• Registrar software no INPI exige certificado — a conta Gov.br não basta
• A marca-d’água do Claude não prova autoria — e uma reescrita pode apagá-la
• PIN, senha e código do WhatsApp não são iguais — proteja a conta sem se bloquear