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.
Operational summary
At a glance
- Symptom
- Rival CA customer completes domain validation via dangling subdomain, stale NS delegation, or orphaned TXT record
- Likely cause
- Bare CAA issue tag omitting RFC 8657 accounturi and validationmethods parameters
- Impact
- Attacker obtains a CT-logged, CAA-compliant certificate for the domain, enabling trusted MITM or phishing with no policy violation flagged
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- Add accounturi and validationmethods per RFC 8657; set iodef reporting; monitor CT logs filtered by account ID
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
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.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
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 ";"Verify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.