CAA Records Restrict CAs, Not Accounts Inside Them
A CAA record naming only the issuing CA's hostname, such as issue "letsencrypt.org", authorises every customer of that CA, not a single account. Any other tenant who passes domain control validation through a stale subdomain, dangling delegation, or orphaned TXT record can obtain a fully CAA-compliant certificate, invisible to standard compliance checks.
At a glance
- Unsafe setting
- Bare CAA issue tag omitting RFC 8657 accounturi and validationmethods parameters
- Failure trigger
- Rival CA customer completes domain validation via dangling subdomain, stale NS delegation, or orphaned TXT record
- Blast radius
- Attacker obtains a CT-logged, CAA-compliant certificate for the domain, enabling trusted MITM or phishing with no policy violation flagged
- Recommended control
- Add accounturi and validationmethods per RFC 8657; set iodef reporting; monitor CT logs filtered by account ID
Fix commands and configuration
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"issuewildissuewild ";"The Trap
A CAA record configured with a bare issue tag, such as issue "letsencrypt.org", with no accounturi or validationmethods parameter from RFC 8657.
The Default State
Route 53, Cloudflare and most managed DNS consoles ship CAA templates that only populate the CA hostname. Engineers copy the sample record, confirm dig CAA example.com returns something, and treat the zone as locked down. Nobody adds the parameters that actually scope the authorisation to a single account.
The Blast Radius
CAA restricts which CA hostname may issue for a domain, not which customer account under that CA. If your policy says letsencrypt.org, any other Let’s Encrypt customer can still obtain a valid certificate for your name provided they pass domain control validation through some other path: a dangling load balancer still answering HTTP-01 challenges on a decommissioned subdomain, a stale NS delegation left pointing at an old provider, or an orphaned TXT record on a subdomain nobody monitors. The resulting certificate is fully CAA-compliant and appears in Certificate Transparency logs as legitimate, because the CA correctly checked the policy tag and found itself permitted. Security teams checking CAA compliance see a green result while an attacker-controlled certificate sits ready for a MITM proxy or phishing kit that browsers will trust without warning.
The Lead Mechanic Fix
Pin the record to a specific account and validation method: example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01". Repeat for issuewild if wildcard issuance is required, or set issuewild ";" to forbid it outright. Add iodef "mailto:pki-alerts@company.com" so compliant CAs report policy violation attempts. Then run continuous CT monitoring against crt.sh or a Cert Spotter subscription filtered by account ID, not just CA hostname, since account-scoped anomalies are what the plain CAA record cannot itself prevent.