The fix, in one snippet
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now queries CAA records for the hostname and, as RFC 8659 section 3 requires of certificate authorities, walks up the parent labels until it finds a CAA set or reaches the registrable domain. It reports the issue, issuewild and iodef properties found, together with any RFC 8657 parameters (validationmethods, accounturi). A missing CAA set is a low-severity finding. Two configuration problems are also flagged: a CAA that does not include the issuer of the certificate currently served (renewal will fail at the next attempt, since CAs check CAA at issuance time), and the critical flag (128) on a property tag the scanner does not recognise, which makes every CA refuse to issue. A record of issue ";" is reported as "deliberately blocks all issuance" rather than as an error. Only DNS lookups are involved; no certificate request is made.
Why it matters
Every publicly trusted CA can issue a certificate for any domain that passes its domain-validation check, and validation is automated: an HTTP file, a DNS record or an email. Attacks on that process, such as BGP hijacks that intercept validation traffic, DNS spoofing against the CA's resolvers, or simply compromising an under-secured CA, have all produced mis-issued certificates. CAA lets you say in DNS which CAs are permitted, and the CA/Browser Forum has required CAs to check it before issuing since September 2017. An attacker then has to compromise your CA specifically rather than the weakest one on the internet. The accounturi parameter goes further and pins issuance to your own ACME account, and iodef gets you an email when a CA refuses a request, which is an early warning that someone tried. It costs one DNS record. Related: dnssec, which protects the CAA lookup itself from spoofing, and certificate-valid.
How to fix it
Publish CAA records naming the CAs you use. Identifier strings for common CAs: letsencrypt.org, digicert.com, sectigo.com, pki.goog (Google Trust Services), globalsign.com, amazon.com (AWS Certificate Manager), ssl.com. A typical set for a domain using Let's Encrypt with no wildcard certificates:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:[email protected]"Pin issuance to your ACME account and validation method (Let's Encrypt supports both parameters):
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"In the Cloudflare DNS dashboard: Type CAA, flags 0, tag issue, CA domain name as above. If Cloudflare Universal SSL manages your edge certificate, Cloudflare adds CAA records for its own CAs automatically when you create any CAA record, so that its certificates keep renewing. Route 53 and most registrars have equivalent forms. Check the result and confirm your current issuer is covered:
dig +short CAA example.comThen run a renewal dry-run (certbot renew --dry-run) to prove issuance still works before the next real renewal.
Where this fits
CAA record is check 4 of 8 that the website vulnerability scanner runs under dns and email authentication, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits SPF record (medium), where the domain publishes no valid SPF record, or publishes more than one, so receiving mail servers cannot tell which hosts are allowed to send mail as your domain. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
CAA record closes one route in. Immediately below it: DMARC policy is p=none (monitoring only), where the DMARC record exists but uses p=none, so receivers are asked to deliver spoofed mail normally; DNSSEC signing, where the domain's DNS zone is not signed with DNSSEC, so a resolver cannot verify that the answers it receives for your domain are genuine, or the zone is signed but validation is failing; DKIM selector discovered, where no DKIM public key was found under the common selector names, or the key found is weak or revoked.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: CAA record (low severity)
Scanner check id: caa-recordThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.