Defaults.Exposed › Correções › Registos CAA

Como corrigir Registos CAA

Um registo CAA é uma instrução curta nas definições do seu domínio que nomeia quais as empresas de certificados autorizadas a emitir o certificado de segurança do «cadeado» do seu site. Com ele ativado, nenhuma outra empresa pode criar discretamente um certificado válido em seu nome.

O essencial para o seu negócio: Sem um registo CAA, quase qualquer uma das centenas de empresas de certificados no mundo pode emitir um certificado de cadeado genuíno e totalmente confiável para o seu domínio — permitindo a um burlão montar um clone impecável e de aparência totalmente «segura» do seu site para colher os inícios de sessão e os dados de cartão dos seus clientes, sem nada no ecrã que os avise.

Quanto isto lhe pode custar

Um burlão obtém um certificado real para uma cópia do seu site, por isso ele mostra o cadeado verde e o HTTPS — os seus clientes não veem nada de errado, introduzem as palavras-passe e os números de cartão, e só fica a saber quando começam os estornos e as chamadas irritadas.
Os seus clientes são vítimas de phishing através de uma cópia perfeita ao pixel da sua página de início de sessão; as consequências — reembolsos, carga de apoio, dano de reputação — caem sobre a sua marca, mesmo que o seu site real nunca tenha sido tocado.
A equipa de segurança ou de compras de um potencial cliente faz uma verificação rápida ao seu domínio antes de assinar, não vê proteção CAA e marca-o discretamente como «fraco no básico» — pondo em risco um negócio por uma definição que demora cinco minutos a adicionar.
Uma das empresas de certificados do mundo é comprometida (isto já aconteceu repetidamente — DigiNotar, Comodo, Symantec) e, como nunca disse quem está autorizado a agir por si, o seu domínio fica exposto a quem se revelar o elo mais fraco.

Por que importa. Neste momento a porta está escancarada: qualquer empresa de certificados na Terra pode atestar por um site que diz ser o seu, quer alguma vez tenha lidado com ela ou não. Um registo CAA tranca essa porta para que só o fornecedor que escolheu possa emitir certificados — é a defesa mais simples e barata que existe contra alguém que se faça passar pela sua empresa online.

Registos CAA, em palavras simples

Todos os sites seguros têm um certificado — aquilo que está por trás do cadeado no navegador e do «https» no início do seu endereço. Esses certificados são emitidos por empresas especializadas chamadas autoridades de certificação (CAs): nomes como Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Quando o seu navegador vê um certificado válido, mostra o cadeado e diz ao seu cliente que a ligação é genuína e segura.

Eis a parte que à maioria dos proprietários nunca foi contada: por omissão, centenas dessas autoridades de certificação por todo o mundo estão, cada uma, autorizadas a emitir um certificado para o seu domínio — quer já tenha ouvido falar delas ou não. Um registo CAA (Certification Authority Authorization) é uma nota de uma linha que adiciona às definições de DNS do seu domínio e que diz, na prática, «só estes fornecedores estão autorizados a emitir certificados por mim». Todas as autoridades de certificação legítimas são obrigadas pelas regras da indústria a verificar essa nota antes de emitir — e a recusar se não estiverem na sua lista.

É a diferença entre uma porta da frente destrancada por onde qualquer um pode entrar e uma em que só as pessoas que escolheu têm a chave. E não custa nada adicionar.

O que isto lhe pode custar

O risco que um registo CAA fecha é a personificação convincente. Quando um burlão consegue obter um certificado real para uma cópia do seu site, os sinais de alerta habituais desaparecem — não há cadeado partido, nem aviso de «não seguro», nem erro de certificado. Tudo parece certo, que é exatamente o que o torna perigoso.

A falsificação impecável. Um burlão regista um endereço parecido (ou compromete uma rota até aos seus clientes), obtém um certificado genuíno e monta um clone perfeito da sua página de início de sessão ou de checkout — cadeado e tudo. Os clientes introduzem palavras-passe e números de cartão como de costume. A primeira coisa que ouve é uma onda de estornos, denúncias de fraude e chamadas irritadas.
A campanha de phishing em seu nome. Os atacantes enviam e-mails de «por favor confirme a sua conta» que ligam ao clone certificado do seu site. Como a página parece totalmente segura, mais pessoas caem. A limpeza — notificar clientes, reembolsos, horas de apoio, a explicação pública embaraçosa — cai toda sobre si, mesmo que os seus servidores reais nunca tenham sido tocados.
O negócio que trava numa lista de verificação. A equipa de segurança ou de compras de um cliente maior analisa o seu domínio antes de assinar. «Sem registo CAA» aparece como um item vermelho ou amarelo ao lado do seu nome. É uma coisa pequena tecnicamente, mas lê-se como «não cobre o básico», e pode atrasar ou afundar um contrato que de outra forma teria ganho.
Apanhado pela violação de outra pessoa. Uma autoridade de certificação com quem nunca lidou é comprometida — isto não é hipotético; a DigiNotar, a Comodo e a Symantec tiveram todas incidentes graves. Como nunca restringiu quem podia agir por si, o atacante pode obter um certificado válido para o seu domínio através dessa CA fraca. Um registo CAA tê-lo-ia recusado.
O ponto cego dos wildcards. Até as empresas cuidadosas com o seu site principal esquecem muitas vezes os subdomínios. Sem uma regra issuewild, um atacante que consiga obter um certificado wildcard fica, na prática, com uma chave para todos os subdomínios que alguma vez terá, de uma só vez.

Nenhum destes cenários exige um ataque sofisticado aos seus servidores. Exploram o facto de que, sem um registo CAA, o sistema de certificados mais amplo é simplesmente demasiado confiante em seu nome.

O que isto é, na realidade, e o que é «bom»

Um registo CAA vive no DNS do seu domínio — as mesmas definições que apontam o seu domínio para o seu site e o seu e-mail. Cada registo tem três partes: uma flag, uma tag e um valor. As tags que importam são:

issue — nomeia uma autoridade de certificação autorizada a emitir certificados normais para o seu domínio. Pode ter várias, uma por cada fornecedor que use legitimamente.
issuewild — controla os certificados wildcard (um certificado que cobre todos os subdomínios, p. ex. *.exemplo.com). Se não usa wildcards, a definição recomendada bloqueia-os por completo.
iodef — um endereço de contacto opcional para onde será notificado se uma autoridade de certificação rejeitar um pedido por causa da sua política CAA. É o seu aviso prévio de que alguém tentou.

O que é «bom»: pelo menos um registo issue (ou issuewild) está presente, a nomear o(s) fornecedor(es) que realmente usa, com os wildcards ou restritos a um fornecedor nomeado ou bloqueados. É essa a fasquia que esta verificação mede — procura os registos CAA do seu domínio em vários resolvedores independentes e é aprovada quando encontra uma política issue ou issuewild real implementada. Um domínio sem registos CAA é tratado como a porta aberta que é.

Isto afeta a minha nota? Sim. Um registo CAA em falta é um item pontuado e é assinalado com severidade média — é uma falha genuína, não apenas um extra simpático, porque deixa aberta uma via real de personificação. Adicionar o registo fecha a falha e limpa a conclusão.

Como corrigir (gratuito, ~5 minutos)

Entregue esta secção a quem gere o seu domínio ou site — a correção é gratuita. É uma pequena alteração de DNS, não uma reconstrução. Só cobramos se mais tarde quiser que continuemos a vigiar que o registo se mantém ativo; adicioná-lo não custa nada.

Passo 1 — Descubra qual a autoridade de certificação que realmente usa. Este é o passo que vale a pena acertar, porque listar o fornecedor errado pode bloquear a sua próxima renovação. Casos comuns:

Let’s Encrypt — usada por muitos alojamentos e painéis de controlo (cPanel, Plesk) → letsencrypt.org
Cloudflare (se emite o seu certificado de borda) → letsencrypt.org, digicert.com, comodoca.com, pki.goog e ssl.com (a Cloudflare usa várias CAs de retaguarda; liste as que o painel dela mostra, ou o conjunto completo, para que as renovações nunca partam)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (e comodoca.com)
Microsoft 365 / Azure — a Microsoft usa normalmente a DigiCert para certificados geridos → digicert.com (confirme no seu portal)

Se tiver dúvidas, veja o seu certificado atual no navegador (clicar no cadeado → detalhes do certificado → «Emitido por») para ver quem o emitiu.

Passo 2 — Inicie sessão no seu fornecedor de DNS. É onde os registos do seu domínio vivem — normalmente o seu registrar, o seu alojamento web ou a Cloudflare. Encontre a secção de registos DNS e escolha adicionar um novo registo do tipo CAA (algumas interfaces rotulam-no como tipo 257).

Passo 3 — Adicione um registo issue para cada fornecedor que use. Para a Let’s Encrypt, por exemplo:

exemplo.com.   CAA   0 issue "letsencrypt.org"

Adicione uma linha issue por cada fornecedor legítimo. A maioria dos painéis de DNS dá-lhe caixas separadas para a flag (0), a tag (issue) e o valor (o domínio da CA), para não escrever a linha inteira à mão.

Passo 4 — Controle os certificados wildcard. Se não usa wildcards, bloqueie-os de imediato para que ninguém possa obter um discretamente:

exemplo.com.   CAA   0 issuewild ";"

Se usa wildcards, nomeie antes o fornecedor: 0 issuewild "letsencrypt.org".

Passo 5 — (Recomendado) Adicione um endereço de notificação. Para ser avisado sempre que uma CA rejeitar uma tentativa — o seu aviso prévio de que alguém tentou:

exemplo.com.   CAA   0 iodef "mailto:[email protected]"

Passo 6 — Guarde e verifique. Corra dig CAA exemplo.com (ou use qualquer ferramenta de consulta de DNS online) e confirme que os seus registos aparecem. As alterações podem levar de alguns minutos a algumas horas a espalhar-se pela internet. O seu certificado existente e todas as renovações continuam a funcionar — o CAA só rege a nova emissão.

Notas rápidas por plataforma: Na Cloudflare, DNS → Records → Add record → tipo CAA. No Google Workspace, gere o DNS no seu registrar (ou no Cloud DNS, se o usar) — adicione lá os registos CAA com pki.goog. No Microsoft 365, o CAA não se define no centro de administração do M365; adicione-o onde o DNS do seu domínio está alojado, listando a CA do seu certificado gerido (geralmente a DigiCert). Em alojamentos comuns (GoDaddy, Namecheap, e outros), está no mesmo painel de DNS onde vivem os seus registos A e MX.

Erros comuns

Listar a CA errada — ou esquecer uma. O maior risco do mundo real não é a segurança, é bloquear as suas próprias renovações. Se usa mais do que um emissor (p. ex. um para o site principal e outro por trás da Cloudflare), liste-os todos. Na dúvida, liste alguns em que confia em vez de poucos de menos.
Definir issue mas ignorar os wildcards. Um domínio que restringe os certificados normais mas nada diz sobre os wildcards continua a deixar aberta a via wildcard, mais poderosa. Defina sempre também o issuewild — quer para o seu fornecedor, quer para ";" para o bloquear.
Pôr o CAA no nome errado. O CAA é lido pela autoridade de certificação para o nome exato a certificar, subindo a árvore. Defini-lo no topo do seu domínio (o «apex», p. ex. exemplo.com) é a jogada certa — cobre os subdomínios por omissão, a menos que um subdomínio defina o seu próprio.
Assumir que a sua plataforma já o fez. A Cloudflare, a Google e a Microsoft gerem certificados mas não adicionam registos CAA por si. A menos que os tenha adicionado, o seu domínio continua aberto.
Tratá-lo como uma coisa única e sem monitorização. Uma migração de DNS posterior, uma mudança de registrar ou uma «arrumação» de registos podem deixar cair silenciosamente a sua proteção CAA. Vale a pena verificar se continua lá após qualquer alteração de DNS.

A camada técnica (entregue isto ao seu responsável de TI)

O CAA está definido no RFC 8659 e é imposto ao abrigo dos Baseline Requirements do CA/Browser Forum — toda a CA publicamente confiável é obrigada a verificar o CAA no momento da emissão. Os registos têm a forma <flags> <tag> <valor>, com as tags issue, issuewild e iodef. Uma política issue ou issuewild não vazia é o que satisfaz esta verificação; a presença de iodef por si só não basta (é relatório, não autorização).

Uma base sólida no apex:

exemplo.com.   CAA   0 issue "letsencrypt.org"
exemplo.com.   CAA   0 issuewild ";"
exemplo.com.   CAA   0 iodef "mailto:[email protected]"

Notas para o implementador:

Subida da árvore CAA: as CAs avaliam o CAA a partir do FQDN pedido para cima, até ao apex, parando no primeiro nome com um registo CAA definido. Um registo no apex protege, portanto, todos os subdomínios, a menos que um subdomínio publique o seu próprio, o que pode fazer — útil se um subdomínio específico usar um emissor diferente.
O valor ; em issuewild significa «nenhuma CA pode emitir wildcards» — uma recusa explícita. Use-o sempre que os wildcards não façam parte da sua configuração.
A flag 0 é a flag issuer-critical; 0 (não crítica) é o correto para uso normal. Evite definir o bit crítico a menos que o compreenda totalmente, pois uma tag crítica mal entendida pode levar CAs conformes a recusar a emissão.
Múltiplos emissores: vários registos issue são permitidos e aditivos — liste todas as CAs legitimamente na sua pilha (incluindo as CAs de retaguarda que o seu fornecedor de CDN/borda usa) para evitar falhas de renovação.
Verificação: dig CAA exemplo.com +short, ou verifique através das ferramentas de teste de CAA do CA/Browser Forum. Esta verificação em si consulta o CAA em vários resolvedores independentes (DNS local, depois Google, Cloudflare e Quad9 via DNS-over-HTTPS como recurso) e aceita a primeira resposta autoritativa, por isso uma falha de um único resolvedor não produzirá um falso «sem CAA».
Emparelhamento com DNSSEC: o CAA diz às CAs quem pode emitir; o DNSSEC impede que a própria resposta CAA seja forjada em trânsito. São complementares — para domínios de alto valor, execute ambos.

Configure no seu fornecedor

Passo a passo para os fornecedores mais populares:

Perguntas frequentes

Não percebo de tecnologia — posso tratar disto sozinho?

Não precisa de perceber o detalhe, mas a correção é uma pequena alteração dentro das definições de DNS do seu domínio, por isso é melhor entregá-la a quem gere o seu site ou domínio. Envie-lhe a secção «Como corrigir» mais abaixo — é uma alteração de cinco minutos, sem custos. Só cobramos se mais tarde quiser que continuemos a vigiar que o registo se mantém ativo; a correção em si é sempre gratuita.

Adicionar isto vai partir o meu site ou o meu certificado?

Não — desde que liste o fornecedor de certificados que realmente usa, tudo continua a funcionar exatamente como antes. Um registo CAA não toca nem substitui o seu certificado existente; só rege quem está autorizado a criar novos. A única forma de causar problemas é deixar o seu fornecedor real fora da lista, o que pode bloquear a sua próxima renovação automática — os passos abaixo estão escritos especificamente para o evitar.

Se hoje em dia os certificados são emitidos automaticamente, por que ainda preciso disto?

Os certificados automáticos são bons e convenientes — o problema é que o sistema está, por omissão, aberto a toda a gente, incluindo a quem se faz passar por si. Um registo CAA simplesmente nomeia quem está autorizado, transformando uma porta aberta numa porta com o seu próprio cadeado. Funciona ao lado da emissão automática, não contra ela.

Isto afeta o meu posicionamento no Google ou a minha nota neste relatório?

Afeta a sua nota de segurança aqui — um registo CAA em falta é um item pontuado, marcado como falha de severidade média, porque deixa aberta uma via real de personificação. Não é um fator direto de posicionamento no Google, mas a personificação e o phishing que previne são exatamente o tipo de incidentes que danificam a confiança e o tráfego. De qualquer forma, é uma vitória rápida e gratuita.

Qual é a diferença entre «issue» e «issuewild»?

Um registo «issue» controla os certificados normais para o seu domínio e os seus subdomínios. Um registo «issuewild» controla os certificados wildcard — o único certificado que cobre de uma vez todos os subdomínios possíveis (como *.exemplo.com). Os wildcards são mais poderosos e, por isso, mais arriscados em mãos erradas, pelo que é boa prática controlá-los em separado: se não usa wildcards, bloqueie-os de imediato.

Usamos Cloudflare / Google Workspace / Microsoft 365 — isso já cobre isto?

Não automaticamente. Essas plataformas gerem os seus certificados por si, mas a menos que tenha adicionado explicitamente registos CAA, o seu domínio continua a dizer ao mundo «qualquer autoridade pode emitir». A boa notícia é que a correção é a mesma alteração de DNS simples em todas elas, e quando a Cloudflare ou o seu alojamento emite o seu certificado, basta listar esse fornecedor. As notas por plataforma na secção de correção cobrem os casos comuns.