Registros DNS CAA: o guia completo para controlar quem emite os seus certificados

⚡TL;DR

• Um registro DNS CAA declara quais autoridades de certificação têm o direito de emitir um certificado TLS para o seu domínio. Sem CAA, qualquer CA pública pode fazê-lo.
• A sintaxe se resume a três campos: flag tag value. As tags úteis são issue (certificados clássicos), issuewild (wildcards) e iodef (notificação de tentativas não autorizadas).
• A CA verifica o CAA no momento da emissão subindo o DNS do subdomínio em direção ao apex (tree climbing) e para no primeiro registro encontrado (RFC 8659).
• A RFC 8657 adiciona accounturi e validationmethods para vincular a emissão a uma conta ACME específica e a métodos de validação autorizados.
• Uma configuração CAA mal pensada (issuewild esquecido, ponto e vírgula mal compreendido, CA ausente) pode bloquear as suas renovações ACME automáticas.

O modelo de confiança dos certificados TLS repousa sobre uma centena de autoridades de certificação (CA) reconhecidas pelos navegadores. O problema é estrutural: por padrão, qualquer uma dessas CA pode emitir um certificado válido para o seu domínio, sem o seu consentimento e sem sequer avisá-lo. Um atacante que consiga enganar uma única CA, ou uma CA que cometa um erro, pode produzir um certificado perfeitamente reconhecido para captaindns.com.

O registro DNS CAA (Certificate Authority Authorization), definido pela RFC 8659, fecha uma parte dessa porta. Ele atua como uma lista de permissões publicada na sua zona DNS: antes de emitir um certificado, uma CA em conformidade deve consultar o DNS e verificar se realmente figura nos seus registros CAA. Se não estiver lá, ela se recusa a emitir. É uma barreira à emissão, não uma detecção a posteriori.

Este guia se destina aos administradores de sistemas, às equipes de DevOps e SRE e aos responsáveis pela segurança. Ele cobre o modelo de ameaça, a sintaxe completa de um registro CAA (tags issue, issuewild, iodef, flag crítica), o mecanismo exato de validação por subida de árvore, os parâmetros avançados da RFC 8657 para o ecossistema ACME, a configuração concreta nos principais provedores e os erros que quebram as renovações automáticas.

O problema: qualquer CA pode emitir um certificado

Quando o seu navegador abre uma conexão HTTPS, ele verifica se o certificado apresentado foi assinado por uma autoridade de certificação presente no seu armazém de confiança. Esse armazém contém uma centena de CA raiz, gerenciadas por organizações muito diversas, espalhadas por vários países.

Uma confiança horizontal e sem compartimentação

A falha de concepção é simples de enunciar: a confiança é horizontal. O navegador confia em todas as CA do seu armazém de forma equivalente. Nada, no protocolo de base, restringe uma CA específica a um subconjunto de domínios. Concretamente, uma CA situada do outro lado do mundo, que você nunca usou, está tecnicamente habilitada a emitir um certificado reconhecido para o seu domínio.

Enquanto todas as CA funcionarem perfeitamente, esse modelo se sustenta. Mas basta que uma única falhe, por erro operacional ou comprometimento, para que um certificado fraudulento seja produzido e aceito por todos os navegadores.

Incidentes bem reais

A história dos certificados TLS é marcada por incidentes de má emissão (mis-issuance):

• DigiNotar (2011): essa CA holandesa foi comprometida. Os atacantes emitiram mais de 500 certificados fraudulentos, incluindo um wildcard para *.google.com, usado para interceptar o tráfego de cidadãos iranianos. A DigiNotar perdeu a confiança dos navegadores e faliu.
• Symantec (2015 a 2017): uma série de emissões não conformes, incluindo certificados de teste para domínios de terceiros emitidos sem autorização, levou o Google e a Mozilla a programar a revogação da confiança concedida à antiga infraestrutura Symantec. A atividade de CA foi cedida à DigiCert.
• Sequestros BGP: vários ataques combinaram sequestro de rotas de rede e validação de domínio para obter certificados fraudulentos. O caso MyEtherWallet (2018) viu atacantes desviarem o tráfego DNS para obter um certificado e roubar fundos.

Esses incidentes compartilham um ponto em comum: um certificado tecnicamente válido foi emitido para um domínio sem o consentimento do seu proprietário. A pesquisa acadêmica confirmou que esse risco não tem nada de anedótico. O estudo "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018) demonstrou que um atacante podia obter certificados fraudulentos das maiores CA desviando as consultas de validação de domínio via BGP, com uma taxa de sucesso elevada.

A lição é que uma única falha em qualquer uma das CA de confiança basta para comprometer qualquer domínio. É precisamente a amplitude dessa superfície de ataque que o CAA vem reduzir, limitando a lista das CA habilitadas a emitir para um determinado domínio.

A detecção não basta

A Certificate Transparency (CT) impõe desde 2018 que todo certificado público seja registrado em logs públicos e verificáveis. É um progresso importante: um proprietário de domínio pode monitorar esses logs e detectar um certificado emitido sem o seu conhecimento.

Mas a Certificate Transparency é um mecanismo de detecção a posteriori. No momento em que você detecta um certificado fraudulento em um log, ele já foi emitido e talvez já tenha sido usado. O CAA ataca o problema a montante: ele impede a emissão em vez de constatá-la depois. Os dois mecanismos são complementares.

O que é um registro CAA?

Um registro DNS CAA (Certificate Authority Authorization, RFC 8659) indica quais autoridades de certificação estão autorizadas a emitir certificados TLS para um domínio. Antes de cada emissão, a CA consulta o DNS do domínio e se recusa a emitir se não figurar na lista publicada. É uma autorização prévia, controlada pelo proprietário do domínio por meio da sua zona DNS.

Um tipo de registro DNS dedicado

O CAA é um tipo de registro DNS por inteiro, o tipo 257. Ele é publicado na sua zona exatamente como um registro A, MX ou TXT. Você pode colocá-lo no apex da zona (captaindns.com) ou em um subdomínio específico (api.captaindns.com).

Aqui está um exemplo mínimo que autoriza apenas a Let's Encrypt a emitir certificados para o domínio:

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"

Esse registro declara uma única coisa: a única CA autorizada a emitir um certificado para captaindns.com é a Let's Encrypt, identificada pelo seu domínio letsencrypt.org. Qualquer outra CA em conformidade que receba uma solicitação para esse domínio a recusará.

Um ponto essencial sobre a semântica: a presença de um único registro issue transforma a política implícita. Sem CAA, todas as CA são autorizadas por padrão. Assim que um issue existe, o padrão se inverte: apenas as CA explicitamente listadas são autorizadas, todas as outras são implicitamente proibidas. Adicionar uma CA à sua política consiste, portanto, em publicar um registro issue adicional; esquecer uma equivale a bloqueá-la.

Uma história em duas RFC

O CAA foi primeiramente definido pela RFC 6844 em 2013. Essa primeira versão continha um mecanismo de subida de árvore (tree climbing) considerado ambíguo, sobretudo no tratamento dos erros e dos aliases CNAME/DNAME.

A RFC 8659, publicada em 2019, substitui a RFC 6844 e constitui a referência atual. Ela esclarece o algoritmo de subida e corrige as zonas obscuras da primeira versão. Uma RFC complementar, a RFC 8657 (2019), adiciona dois parâmetros orientados ao ACME: accounturi e validationmethods. Tratamos desses parâmetros em uma seção dedicada.

Uma barreira, não uma garantia absoluta

O CAA repousa sobre a cooperação das CA. Todas as CA publicamente reconhecidas, sujeitas aos Baseline Requirements do CA/Browser Forum, são obrigadas a verificar o CAA antes da emissão. É uma exigência do marco normativo, não uma opção. Na prática, as principais CA aplicam essa verificação.

O CAA não protege, portanto, contra uma CA desonesta que decida ignorar deliberadamente os seus registros, nem contra uma CA privada interna a uma organização. Mas ele eleva fortemente a barreira: para emitir um certificado fraudulento apesar de um CAA bem configurado, um atacante teria que comprometer a CA que você autorizou explicitamente, ou falsificar as suas respostas DNS no momento do controle. Esse último ponto nos leva à relação entre CAA e DNSSEC, abordada mais adiante.

Anatomia de um registro CAA

Um registro CAA se resume a três campos, sempre na mesma ordem. Dominar essa sintaxe é indispensável para não errar a configuração.

A estrutura flag tag value

Cada registro CAA é composto por três elementos:

Campo	Função	Valores
flag	Inteiro de controle	0 (não crítico) ou 128 (crítico)
tag	Propriedade visada	issue, issuewild ou iodef
value	Valor da propriedade	Identificador da CA, ou URL de notificação

Lido da esquerda para a direita, o registro 0 issue "letsencrypt.org" se traduz por: flag não crítica, propriedade issue, valor letsencrypt.org. O valor está sempre entre aspas retas na representação textual.

A tag issue: autorizar uma CA para os certificados clássicos

A tag issue autoriza uma CA a emitir certificados não wildcard para o domínio. O valor é o identificador da CA, geralmente um nome de domínio.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  IN  CAA  0 issue "digicert.com"

Esse exemplo autoriza duas CA: Let's Encrypt e DigiCert. Quando vários registros issue coexistem, eles se somam: toda CA listada é autorizada. É uma lista de permissões cumulativa.

Um caso particular merece atenção: o valor ";" (um simples ponto e vírgula). Ele proíbe qualquer emissão.

captaindns.com.  IN  CAA  0 issue ";"

Esse registro declara que nenhuma CA está autorizada a emitir certificado clássico para o domínio. Isso é útil para um domínio que nunca deve portar um certificado (um domínio de parking, por exemplo), mas também é uma fonte de erro frequente quando é colocado por descuido.

A tag issuewild: o caso dos wildcards

A tag issuewild controla especificamente a emissão dos certificados wildcard (do tipo *.captaindns.com). A sua sintaxe é idêntica à de issue.

A regra de prioridade é essencial: issuewild prevalece sobre issue para os certificados wildcard. Se um registro issuewild está presente, é ele que vale para as solicitações wildcard, e os registros issue são ignorados nesse caso. Se nenhum issuewild está presente, os certificados wildcard recaem sobre as regras issue.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org"
captaindns.com.  IN  CAA  0 issuewild "digicert.com"

Nesse exemplo, os certificados clássicos só podem ser emitidos pela Let's Encrypt, enquanto os certificados wildcard só podem ser emitidos pela DigiCert. Para proibir pura e simplesmente qualquer certificado wildcard, usa-se o ponto e vírgula:

captaindns.com.  IN  CAA  0 issuewild ";"

Isso bloqueia qualquer emissão de wildcard, deixando os certificados clássicos seguirem as regras issue.

A tag iodef: notificar as tentativas não autorizadas

A tag iodef (Incident Object Description Exchange Format) indica onde uma CA deve notificar uma solicitação de certificado que viola a sua política CAA. O valor é uma URL, seja um email no formato mailto:, seja uma URL HTTPS.

captaindns.com.  IN  CAA  0 iodef "mailto:security@captaindns.com"
captaindns.com.  IN  CAA  0 iodef "https://captaindns.com/caa-report"

Quando uma CA recebe uma solicitação que recusa por causa do seu CAA, ela pode enviar um relatório para o endereço iodef. É um sinal precioso: uma tentativa de emissão não autorizada pode indicar um ataque em curso ou um serviço interno mal configurado. O suporte ao iodef varia conforme as CA; é preciso considerá-lo como um bônus de visibilidade, não como uma garantia de notificação.

Na prática, um relatório iodef merece uma investigação imediata. Ou um dos seus serviços tenta emitir um certificado por meio de uma CA que você esqueceu de autorizar (problema de configuração), ou um ator externo tenta obter um certificado para o seu domínio (problema de segurança). Nos dois casos, o iodef lhe dá uma visibilidade que nem a Certificate Transparency nem os logs da sua infraestrutura fornecem, pois ele capta a tentativa no momento exato da recusa.

A flag crítica: 0 contra 128

O primeiro campo, a flag, é um octeto do qual apenas o bit de maior peso (valor 128, ou seja 0x80) tem um significado definido: é a flag crítica (issuer critical).

• Flag 0: registro não crítico. Se uma CA não compreende a tag, ela a ignora e continua.
• Flag 128: registro crítico. Se uma CA encontra uma tag que não compreende com essa flag posicionada, ela deve se recusar a emitir.

A flag crítica serve para se precaver contra a introdução futura de tags que as CA antigas não saberiam interpretar. Ao colocar a flag 128 em uma tag, você exige que toda CA que não a compreenda se abstenha, por segurança, em vez de ignorá-la. Na grande maioria das configurações, a flag permanece em 0: as tags issue, issuewild e iodef são universalmente compreendidas.

Os identificadores das CA comuns

O valor de uma tag issue ou issuewild é o identificador da CA, definido por cada autoridade na sua documentação. Aqui estão os identificadores das principais CA:

Autoridade de certificação	Identificador CAA
Let's Encrypt	letsencrypt.org
DigiCert	digicert.com
Sectigo	sectigo.com
GlobalSign	globalsign.com
Google Trust Services	pki.goog
Amazon (AWS Certificate Manager)	amazon.com (e amazontrust.com, amazonaws.com, awstrust.com)

Use sempre o identificador exato publicado pela CA, e não uma aproximação. Um valor incorreto equivale a não autorizar a CA, e o certificado será recusado. Em caso de dúvida sobre o identificador de uma CA não listada aqui, consulte a sua documentação oficial em vez de adivinhar.

Como a validação CAA funciona

A força do CAA reside no seu mecanismo de validação no momento da emissão. Compreender esse mecanismo evita a maior parte dos erros de configuração.

A subida de árvore (tree climbing)

Quando uma CA trata uma solicitação de certificado para um nome específico, ela não se contenta em olhar o CAA desse nome exato. Ela sobe a hierarquia DNS, rótulo por rótulo, do nome solicitado em direção ao apex da zona, até encontrar um conjunto de registros CAA. É o tree climbing, definido na seção 3 da RFC 8659.

Tomemos uma solicitação para api.captaindns.com. A CA procede assim:

1. Ela consulta o CAA de api.captaindns.com. Se um conjunto CAA estiver publicado ali, ela o utiliza e para.
2. Senão, ela sobe um nível e consulta captaindns.com. Se um conjunto CAA estiver publicado ali, ela o utiliza e para.
3. A subida continua até encontrar um conjunto CAA, ou até atingir a raiz sem encontrar nada.

O ponto-chave: a CA para no primeiro nome que possui registros CAA. Os registros dos níveis superiores não são, então, consultados.

A herança e as suas consequências

Essa mecânica tem uma consequência importante: um subdomínio herda a política CAA do seu pai, mas apenas se não definir a sua própria.

Se você publica um CAA no apex captaindns.com e nada em api.captaindns.com, então api.captaindns.com está sujeito à política do apex. Mas assim que você publica um único registro CAA em api.captaindns.com, a CA para nesse nível e ignora totalmente o apex. A herança é binária: ou o subdomínio não tem nenhum CAA e herda, ou ele tem um e substitui integralmente a política do pai. Não há fusão entre os dois níveis.

É uma fonte de erro clássica: adiciona-se um CAA específico em um subdomínio para autorizar uma CA adicional, sem perceber que esse registro substitui a política do apex em vez de se somar a ela. O subdomínio deve, então, listar todas as CA de que precisa, incluindo aquelas já autorizadas no nível do pai.

A interação com os wildcards

O caso dos certificados wildcard combina duas regras. Primeiro, a prioridade issuewild sobre issue vista acima. Depois, a subida de árvore. Para uma solicitação de *.captaindns.com, a CA procura primeiro um conjunto CAA subindo a árvore, depois aplica dentro desse conjunto a prioridade issuewild. Se o conjunto encontrado contém um issuewild, ele vale para o wildcard; senão, o wildcard recai sobre os issue do mesmo conjunto.

O caso dos aliases CNAME

Quando o nome tratado para a validação CAA aponta para um alias CNAME, a busca CAA segue esse alias. A RFC 8659 precisa que, se um nome é um alias CNAME, a busca CAA prossegue sobre o alvo do alias. É um detalhe que às vezes surpreende: um subdomínio em CNAME para um serviço de terceiros pode, conforme a configuração, depender do CAA do alvo em vez do CAA da sua zona. Quando você delega um subdomínio a um provedor externo via CNAME, verifique qual política CAA se aplica realmente.

O que a CA verifica de fato na emissão

No momento de emitir, uma CA em conformidade com os Baseline Requirements efetua o controle CAA dentro de uma janela temporal limitada (no máximo 8 horas antes da emissão, segundo o marco normativo). Passado esse prazo, o controle deve ser refeito. Essa restrição evita que uma autorização obtida muito antecipadamente permaneça válida depois que você retirou uma CA da sua política.

A CA também deve, desde a implantação da validação multiperspectiva (MPIC, Ballot SC-067), efetuar o controle CAA e a validação de domínio a partir de vários pontos de presença de rede geograficamente distintos. O objetivo é conter os sequestros BGP localizados: se um atacante desvia o tráfego em uma região para falsificar a resposta CAA, as outras perspectivas receberão a resposta legítima e a CA detectará a inconsistência. O MPIC protege, portanto, o controle CAA no nível da rede, enquanto o DNSSEC o protege no nível do protocolo DNS. Os dois mecanismos se reforçam mutuamente.

Concretamente, a sequência de emissão se parece com isto: a CA recebe a solicitação, valida o controle de domínio (DNS-01, HTTP-01 ou TLS-ALPN-01), consulta o CAA subindo a árvore, confirma que figura na lista autorizada, depois emite. Se o CAA a recusa, a emissão para imediatamente e, se um iodef está presente, um relatório pode ser enviado.

A relação com o DNSSEC

O controle CAA repousa sobre respostas DNS. Se um atacante pode falsificar as suas respostas DNS no momento em que a CA consulta o CAA, ele pode enganar o controle. O DNSSEC responde a esse risco autenticando criptograficamente as respostas DNS.

O CA/Browser Forum formalizou essa relação com o Ballot SC-085v2, em vigor desde 15 de março de 2026, que impõe às CA validar DNSSEC, quando presente, durante as consultas CAA e de validação de domínio. Concretamente, se a sua zona está assinada e a cadeia de confiança está intacta, a CA obtém a garantia de que os registros CAA que ela lê são autênticos. Dedicamos um artigo completo a essa mudança regulatória: as CA agora verificam DNSSEC antes de emitir um certificado. Você pode verificar o estado de assinatura da sua zona com o nosso verificador DNSSEC. Para ativar o DNSSEC em um domínio que ainda não o tem, siga o nosso guia de ativação passo a passo.

Parâmetros avançados: a RFC 8657 e o ACME

A RFC 8657 estende o CAA com dois parâmetros que se inscrevem na tag issue ou issuewild. Eles são particularmente úteis em um ecossistema ACME automatizado.

accounturi: vincular uma conta ACME

O parâmetro accounturi restringe a emissão a uma conta ACME específica. Em vez de autorizar qualquer conta de uma dada CA a emitir para o seu domínio, você vincula a autorização ao URI de uma conta ACME única.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Esse registro autoriza a Let's Encrypt a emitir, mas unicamente para a conta ACME numerada 12345678. Uma solicitação proveniente de outra conta Let's Encrypt será recusada. É uma proteção forte: mesmo que um atacante use a mesma CA que você, ele não poderá emitir com a sua própria conta.

validationmethods: restringir os métodos de validação

O parâmetro validationmethods limita os métodos de validação ACME autorizados para o domínio. Os valores correspondem aos tipos de desafio ACME: dns-01, http-01 e tls-alpn-01.

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01"

Aqui, apenas a validação por registro DNS (dns-01) é aceita. Uma tentativa de emissão via http-01 (colocação de um arquivo no servidor web) será recusada. Isso endurece a configuração: se você sabe que os seus certificados são sempre validados por dns-01, proibir os outros métodos reduz a superfície de ataque, por exemplo um servidor web comprometido que tentasse uma validação http-01.

Os três métodos de validação ACME têm perfis de risco distintos. O método dns-01 exige o controle da zona DNS e permite os certificados wildcard. O método http-01 exige o controle do servidor web na porta 80. O método tls-alpn-01 valida via uma extensão TLS na porta 443. Restringir validationmethods ao único método que você usa de fato impede que um atacante que controle apenas um desses vetores obtenha um certificado por uma via que você não havia antecipado.

Combinar os parâmetros para um domínio reforçado

Os parâmetros se acumulam em um mesmo registro, separados por pontos e vírgulas. Uma configuração reforçada típica combina CA, conta e método:

captaindns.com.  IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"

Esse registro autoriza apenas a Let's Encrypt, unicamente via a conta ACME 12345678, e unicamente pelo método dns-01. É o nível de controle mais fino oferecido pelo CAA. Atenção, no entanto: quanto mais estrita a configuração, mais um erro (mudança de conta, migração de método de validação) corre o risco de bloquear uma renovação. O suporte à RFC 8657 também depende da CA; a Let's Encrypt a implementa, mas verifique a documentação da sua CA antes de implantar accounturi ou validationmethods.

Guia prático: configurar CAA no seu provedor

A sintaxe CAA é padrão, mas cada provedor DNS expõe uma interface diferente. Alguns pedem os três campos separadamente (flag, tag, value), outros uma string completa. O tipo de registro é sempre CAA (tipo 257). Aqui estão os procedimentos nos provedores comuns.

Cloudflare

No painel da Cloudflare, vá em DNS e depois em Records, e adicione um registro do tipo CAA. A interface apresenta três campos distintos:

• Flags: deixe 0 na maioria dos casos.
• Tag: escolha issue, issuewild ou iodef na lista suspensa.
• CA domain name (ou Value): digite o identificador, por exemplo letsencrypt.org.

A Cloudflare também oferece uma API e a sua ferramenta de linha de comando para automatizar a criação de registros CAA em uma infraestrutura como código. Observe que a Cloudflare às vezes adiciona automaticamente registros CAA para os seus próprios certificados gerenciados; verifique a lista completa após a modificação para não sobrescrever uma entrada necessária a um serviço Cloudflare.

AWS Route 53

No console Route 53, selecione a sua zona hospedada e crie um registro do tipo CAA. O Route 53 espera o valor no formato completo, uma linha por registro:

0 issue "amazon.com"
0 issue "letsencrypt.org"

Se os seus certificados são gerenciados pelo AWS Certificate Manager (ACM), a Amazon documenta vários identificadores aceitos: amazon.com, amazontrust.com, amazonaws.com e awstrust.com. Você pode autorizar todos eles para cobrir o conjunto dos casos. Lembre-se de manter as outras CA de que você precisa para os serviços fora da AWS.

OVHcloud

Na área de cliente da OVHcloud, abra a zona DNS do seu domínio e adicione uma entrada. Selecione o tipo CAA. A OVHcloud geralmente pede a flag, a tag e o alvo (o valor) em campos distintos. Digite 0 para a flag, a tag desejada, e o identificador da CA para o alvo. Confirme, depois aguarde a propagação.

Gandi

Na interface de gerenciamento DNS da Gandi (LiveDNS), adicione um registro do tipo CAA. A Gandi espera o valor no formato textual completo:

0 issue "letsencrypt.org"

Como nos outros provedores, você pode adicionar várias linhas CAA para autorizar várias CA, ou para adicionar issuewild e iodef. A validação dos certificados Gandi para os domínios hospedados ali se apoia nas CA que eles utilizam; lembre-se de incluí-las se você conta com os certificados deles.

Verificar a propagação após a configuração

Qualquer que seja o provedor, não considere a configuração concluída enquanto você não tiver confirmado que o registro está visível publicamente. Consulte o DNS de fora da sua rede e confirme que o CAA aparece com a flag, a tag e o valor esperados. Leve em conta o TTL: um registro modificado pode permanecer em cache durante a duração do TTL anterior. Em um domínio assinado com DNSSEC, verifique também se o novo registro CAA está corretamente assinado, sem o que um resolvedor validador o rejeitará.

Configurar iodef para a notificação

Qualquer que seja o provedor, a tag iodef é configurada como issue, mas o seu valor é uma URL de notificação em vez de um identificador de CA. Use um endereço de email monitorado pela sua equipe de segurança:

0 iodef "mailto:security@captaindns.com"

Verifique se o endereço é realmente consultado. Um iodef apontando para uma caixa abandonada não serve para nada.

Testar antes de travar

Uma recomendação prudente: comece por uma política permissiva que liste todas as suas CA realmente utilizadas, implante-a, verifique se as renovações passam, depois reforce progressivamente. Leve em conta o TTL dos seus registros: um TTL elevado retarda a aplicação de uma mudança de CA. Antes de uma migração de CA, abaixe o TTL do CAA para acelerar a propagação.

Verificar e auditar os seus registros CAA

Uma vez o CAA implantado, verifique se ele está corretamente publicado e se reflete a sua intenção. Duas abordagens se complementam: a linha de comando e as ferramentas de auditoria.

Ler o CAA com dig

A ferramenta dig consulta diretamente o DNS. Para exibir os registros CAA de um domínio:

dig CAA captaindns.com +short

A saída se parece com isto:

0 issue "letsencrypt.org"
0 issuewild "digicert.com"
0 iodef "mailto:security@captaindns.com"

Cada linha corresponde a um registro CAA, na ordem flag tag value. Se o comando não retornar nada, o domínio não publica nenhum CAA nesse nível. Não esqueça a subida de árvore: um subdomínio sem CAA herda do apex. Para verificar o que api.captaindns.com realmente herda, consulte sucessivamente o subdomínio e depois o apex.

Para ver o detalhe completo, incluindo o TTL e a seção de autoridade, omita a opção +short:

dig CAA captaindns.com

As ferramentas CaptainDNS

A linha de comando mostra o registro bruto, mas não diz se ele é coerente. O CaptainDNS oferece dois níveis de verificação.

O verificador CAA dedicado exibe os seus registros e a sua interpretação, levando em conta a herança por subida de árvore. Ele indica claramente qual CA está autorizada para os certificados clássicos e para os wildcards.

Para uma visão mais ampla, a nossa auditoria de segurança e de entregabilidade agora integra o CAA na sua pontuação. O pilar Segurança DNS combina dois sinais: DNSSEC, que pesa 80 pontos, e CAA, que pesa 20 pontos. Essa ponderação reflete o papel respectivo de cada um: o DNSSEC autentica o conjunto das suas respostas DNS, o CAA restringe especificamente a emissão de certificados. Um domínio que publica um CAA coerente ganha esses 20 pontos e melhora a sua postura de segurança global.

O que verificar

Durante a auditoria, controle alguns pontos precisos:

• Coerência issue e issuewild: a CA que emite os seus wildcards está realmente autorizada por um issuewild, ou você conta com o recuo para issue?
• Nenhuma CA órfã: cada CA que você usa de fato (incluindo para os serviços de terceiros, CDN, gateways de email) figura na lista?
• iodef alcançável: o endereço de notificação é monitorado?
• Sem ponto e vírgula involuntário: um issue ";" colocado por engano bloquearia qualquer emissão.

Erros comuns a evitar

A maior parte dos incidentes ligados ao CAA vem de alguns erros recorrentes. Conhecê-los permite antecipá-los.

Esquecer issuewild. Você publica um issue para a Let's Encrypt e tudo funciona, até o dia em que você solicita um certificado wildcard. Se nenhum issuewild está presente, o wildcard recai sobre issue, o que passa. Mas se você colocou um issuewild para outra CA, ou um issuewild ";", o wildcard será recusado. Verifique sempre a coerência entre issue e issuewild.

Bloquear a sua própria CA. O erro mais direto: esquecer de listar a CA que você usa de fato. Se os seus certificados vêm da Let's Encrypt mas o seu CAA autoriza apenas a DigiCert, a próxima renovação falhará. Esse erro ocorre com frequência após uma mudança de CA ou a adição de um novo serviço.

Quebrar a renovação ACME com uma política estrita demais. Os parâmetros accounturi e validationmethods são poderosos mas rígidos. Se você vincula uma conta ACME e depois recria essa conta (novo identificador), ou se você migra de http-01 para dns-01 sem atualizar o CAA, as renovações automáticas falharão silenciosamente. Em uma infraestrutura ACME automatizada, esse tipo de falha só aparece na expiração do certificado.

Compreender mal a herança. Adicionar um registro CAA em um subdomínio não complementa a política do apex, ele a substitui para esse subdomínio. Um subdomínio com o seu próprio CAA deve listar todas as CA de que precisa. Esquecer esse ponto leva a autorizar uma CA bloqueando acidentalmente a do apex.

O ponto e vírgula mal interpretado. issue ";" proíbe qualquer emissão. Isso é proposital em um domínio que nunca deve portar um certificado, mas é uma armadilha quando se pensa que se trata de um separador ou de um valor vazio. Releia cada registro após a digitação.

A flag errada. Colocar a flag crítica 128 sem compreender o seu efeito pode bloquear CA que não reconhecem uma tag. Na grande maioria dos casos, a flag deve permanecer em 0. Só passe para 128 se você tiver uma razão precisa e compreender quais CA serão afetadas.

Acreditar que o CAA age a posteriori. O CAA é uma barreira à emissão, não um mecanismo de revogação. Ele não revoga um certificado já emitido e não age sobre os certificados existentes. Para monitorar os certificados já produzidos, é a Certificate Transparency que cumpre esse papel.

O CAA no ecossistema da segurança DNS

O CAA não se basta a si mesmo. Ele se inscreve em um conjunto de mecanismos que protegem diferentes etapas do ciclo de vida de um certificado. Confundi-los leva a expectativas equivocadas.

Quatro mecanismos, quatro papéis

Mecanismo	O que protege	Momento de ação
CAA	Qual CA pode emitir	Antes da emissão
Certificate Transparency	Visibilidade dos certificados emitidos	Após a emissão
DANE / TLSA	Qual certificado o cliente deve aceitar	Na conexão
DNSSEC	Autenticidade das respostas DNS	A cada resolução

O CAA age a montante: ele restringe quem pode produzir um certificado. A Certificate Transparency age a jusante: ela torna todo certificado emitido público e, portanto, detectável. O DANE (DNS-based Authentication of Named Entities) age do lado do cliente: ele publica no DNS, via registros TLSA, a impressão digital do certificado que o cliente deve esperar, o que permite rejeitar um certificado válido mas ilegítimo. O DNSSEC sustenta o conjunto: sem respostas DNS autenticadas, nem o CAA nem o DANE são confiáveis.

Uma defesa em profundidade

Esses mecanismos não competem entre si, eles se complementam. O CAA impede a emissão não autorizada. Se uma emissão fraudulenta passa apesar de tudo, a Certificate Transparency permite detectá-la. O DANE permite ao cliente rejeitar um certificado que não corresponde àquele que você publicou. E o DNSSEC garante que os registros CAA e TLSA lidos pelas CA e pelos clientes são autênticos.

Para aprofundar a complementaridade entre CAA e DANE, consulte o nosso guia completo sobre DANE e TLSA. Para compreender em detalhe como o DNSSEC autentica as respostas DNS sobre as quais repousa todo o edifício, leia o nosso artigo sobre a cadeia de confiança DNSSEC.

A estratégia recomendada é clara: publique um CAA coerente para restringir a emissão, assine a sua zona com DNSSEC para autenticar as suas respostas, monitore a Certificate Transparency para detectar qualquer emissão inesperada, e implante o DANE se o seu ecossistema o permitir (sobretudo para o email com MTA-STS e DANE).

Plano de ação recomendado

1. Inventarie as suas CA reais: liste todas as autoridades que emitem certificados para os seus domínios, incluindo os serviços de terceiros (CDN, gateways de email, plataformas cloud).
2. Publique um CAA permissivo: declare primeiro todas as suas CA via issue, adicione issuewild se você usa wildcards, e um iodef para uma caixa monitorada.
3. Verifique a aplicação: controle com dig CAA e confirme que as suas renovações continuam passando.
4. Reforce progressivamente: considere accounturi e validationmethods nos domínios críticos, após ter verificado o suporte da sua CA.
5. Assine a sua zona com DNSSEC: para que o controle CAA seja confiável e conforme às exigências SC-085v2.
6. Monitore: integre a verificação CAA e DNSSEC ao seu monitoramento, e consulte os relatórios iodef.

FAQ

O que é um registro CAA e para que serve?

Um registro DNS CAA (Certificate Authority Authorization, RFC 8659) declara quais autoridades de certificação estão autorizadas a emitir certificados TLS para um domínio. Antes de cada emissão, uma CA em conformidade consulta o DNS e se recusa a emitir se não figurar na lista. O CAA reduz assim o risco de emissão de certificados fraudulentos por uma CA não autorizada.

Um registro CAA é obrigatório?

Não. O CAA é opcional. Sem CAA, qualquer CA publicamente reconhecida pode emitir um certificado para o seu domínio. Publicá-lo é uma boa prática de segurança fortemente recomendada, pois ele restringe explicitamente a lista das CA autorizadas e limita a superfície de ataque ligada à má emissão.

O que acontece se nenhum registro CAA estiver presente?

Na ausência de CAA, uma CA considera que nenhuma restrição é imposta e procede à emissão após os seus controles habituais de validação de domínio. Concretamente, qualquer CA pública pode então emitir um certificado para o seu domínio. O CAA só tem efeito restritivo se for explicitamente publicado.

Qual é a diferença entre as tags issue e issuewild?

A tag issue autoriza uma CA a emitir certificados clássicos (não wildcard). A tag issuewild controla especificamente os certificados wildcard como *.captaindns.com. Se um issuewild está presente, ele prevalece sobre issue para as solicitações wildcard. Se está ausente, os wildcards recaem sobre as regras issue.

Um registro CAA impede realmente a emissão de um certificado fraudulento?

Ele a impede fortemente, mas não de maneira absoluta. O CAA repousa sobre a cooperação das CA, que são obrigadas pelos Baseline Requirements do CA/Browser Forum a verificá-lo. Ele não protege contra uma CA que ignore deliberadamente os seus registros, nem contra uma falsificação das suas respostas DNS. Associado ao DNSSEC, que autentica essas respostas, ele se torna nitidamente mais sólido.

Como verificar um registro CAA com dig?

Use o comando dig CAA captaindns.com +short substituindo pelo seu domínio. Ele exibe os registros CAA no formato flag tag value, por exemplo 0 issue "letsencrypt.org". Se o comando não retornar nada, nenhum CAA está publicado nesse nível, mas o domínio pode herdar a política de um nome pai por subida de árvore.

Como funciona a herança CAA nos subdomínios?

Durante uma solicitação, a CA sobe a hierarquia DNS do subdomínio em direção ao apex e para no primeiro nome que possui registros CAA (tree climbing, RFC 8659). Um subdomínio sem CAA herda, portanto, a política do seu pai. Mas assim que um subdomínio publica o seu próprio CAA, ele substitui integralmente a política do pai para esse subdomínio, sem fusão.

É preciso configurar CAA se eu já uso DNSSEC?

Sim. DNSSEC e CAA respondem a necessidades diferentes. O DNSSEC autentica a integridade das suas respostas DNS, mas não restringe qual CA pode emitir um certificado. O CAA, por sua vez, declara explicitamente as CA autorizadas. O DNSSEC torna confiável o controle CAA (a CA lê registros autênticos), ele não o substitui. Os dois são complementares.

Qual norma define o registro CAA?

O registro CAA é definido pela RFC 8659 (2019), que substitui a RFC 6844 (2013). A RFC 8657 (2019) adiciona os parâmetros accounturi e validationmethods para o ecossistema ACME. A verificação CAA pelas CA é, além disso, imposta pelos Baseline Requirements do CA/Browser Forum.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os arquivos JSON ou CSV abaixo.

• Baixar os identificadores CAA das CA (CSV)
• Baixar os identificadores CAA das CA (JSON)

Glossário

• CAA (Certificate Authority Authorization): tipo de registro DNS (tipo 257) que declara quais autoridades de certificação estão autorizadas a emitir certificados para um domínio.
• CA (Certificate Authority): autoridade de certificação habilitada a emitir certificados TLS reconhecidos pelos navegadores.
• CA/Browser Forum: consórcio das CA e dos editores de navegadores que define os Baseline Requirements, o marco normativo que toda CA pública deve respeitar, incluindo a obrigação de verificar o CAA.
• Tree climbing (subida de árvore): algoritmo pelo qual uma CA sobe a hierarquia DNS do nome solicitado em direção ao apex para encontrar os registros CAA aplicáveis.
• issuewild: tag CAA específica aos certificados wildcard, prioritária sobre issue nesse caso.
• iodef: tag CAA indicando uma URL (mailto ou HTTPS) onde notificar as tentativas de emissão não autorizadas.
• ACME (Automatic Certificate Management Environment): protocolo (RFC 8555) de automação da emissão e da renovação de certificados, utilizado sobretudo pela Let's Encrypt.
• Mis-issuance (má emissão): emissão de um certificado válido para um domínio sem o consentimento do seu proprietário, por erro ou comprometimento da CA.

Fontes

1. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record (IETF)
2. RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding (IETF)
3. CA/Browser Forum: Baseline Requirements
4. Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
5. Let's Encrypt: CAA (documentação oficial)