Apex-Only CAA Records Leave CNAMEd Subdomains Open to Unauthorized Issuance

Symptom

A single-CA certificate authorization policy published at a domain’s apex is trusted to protect every hostname underneath it, yet a specific customer-facing subdomain is later found holding a valid, publicly trusted certificate issued by a certification authority that was never named in that policy. The apex record looks correct in every audit and every DNS lookup against the apex itself confirms the restriction is in place, which is exactly what makes the gap easy to miss.

The affected hostname is usually one that has been delegated to a shared delivery platform, a content delivery network, or an internal multi-tenant edge service through a CNAME, rather than hosted directly under the apex zone.

False Assumption

The team assumed that a Certification Authority Authorization (CAA) record published at a domain’s apex governs certificate issuance for every subdomain of that domain, in the same way a wildcard DNS record or an inherited security policy would. That assumption treats CAA enforcement as a property of the domain name string rather than a property of the specific DNS resolution path a certification authority actually walks before issuing a certificate.

In practice, CAA lookups follow canonical name (CNAME) chains exactly as ordinary DNS resolution does. A hostname that is CNAMEd elsewhere is evaluated against the CAA record set published at the canonical target, not against any record published at its own apex.

Root Cause

The root cause is that CAA resolution transparently follows CNAME redirection, so a CNAMEd subdomain is checked against whatever CAA policy exists at the far end of that chain, which is frequently a shared platform zone carrying no restrictive CAA record at all.

A common shape of this trap: a brand’s apex, company.example, publishes a correct CAA record naming its approved certification authority. A customer-facing hostname, app.company.example, is CNAMEd to a shared delivery zone, edge.internalcdn.net, owned and operated by a separate platform team. That shared zone was never brought into scope when the CAA policy was designed, so it carries no CAA record, or one authorising a broader set of certification authorities for its own operational reasons.

Impact

Any certification authority willing to issue publicly trusted certificates can successfully issue a certificate for the CNAMEd hostname without ever violating a CAA policy, because the resolution path that authority is required to check leads to a zone that imposes no restriction.

This silently defeats the operational purpose of publishing CAA records for that hostname at all: unauthorised or accidental issuance from a CA outside the organisation’s approved list will not be blocked, will not generate a CAA-related rejection to investigate, and will typically only be discovered later through Certificate Transparency log review or an unrelated incident.

Diagnosis

Confirm the exposure by tracing exactly which zone a certification authority’s CAA lookup will resolve to for the affected hostname, rather than trusting the apex record alone.

• Query the CNAME chain for the affected hostname to identify every zone the lookup passes through.
• Query CAA directly at the hostname itself, and separately at every zone the CNAME chain terminates in.
• Cross-check observed issuers for that hostname against Certificate Transparency logs to see whether unapproved issuers have already appeared.

dig CNAME app.company.example +short
dig CAA app.company.example +short
dig CAA edge.internalcdn.net +short

An empty or missing CAA answer at the CNAME target zone, combined with a correctly restrictive record at the apex, confirms the exposure described here.

Correction

The correction is to publish a matching CAA record at every zone a CNAME chain terminates in, not only at the customer-facing apex, so the certification authority’s lookup is restricted regardless of which zone it actually resolves to.

1. Inventory every CNAME target used by customer-facing hostnames across all brand domains in scope.
2. For each unique target zone, confirm with the owning team which certification authorities are actually in use there.
3. Add a CAA record set at that target zone naming only the approved certification authority or authorities, coordinating the change with the owning team before applying it.

; company.example apex (already protected)
company.example.        3600 IN CAA 0 issue "approved-ca.example"

; app.company.example is CNAMEd elsewhere
app.company.example.    3600 IN CNAME edge.internalcdn.net.

; edge.internalcdn.net had no matching CAA record before the fix
edge.internalcdn.net.   3600 IN CAA 0 issue "approved-ca.example"   ; added by this correction

nsupdate -k /etc/named/keys/update.key <<'EOF'
server ns1.internalcdn.net
zone edge.internalcdn.net
update add edge.internalcdn.net. 3600 CAA 0 issue "approved-ca.example"
send
EOF

Apply this change only after inventorying every hostname and approved certification authority that depends on the shared zone; an incomplete issuer list in the new record will block legitimate renewals for other hostnames sharing that same zone.

Validation

Confirm the correction by re-running the CNAME-aware CAA lookup chain and checking that every zone in the path now enforces the intended issuer list.

• Re-run the diagnosis commands against the affected hostname and its CNAME target; every zone in the chain should now return a CAA record naming only approved issuers.
• Review Certificate Transparency logs for the hostname over the prior 90 days and confirm every logged issuer matches the approved list; escalate any mismatch.
• Trigger a test issuance request from the approved certification authority against a non-production hostname sharing the same CNAME target, confirming issuance still succeeds.

Rollback

If the newly published CAA record at the shared CNAME target zone blocks a legitimate renewal from a certification authority that was inadvertently omitted, remove or amend that record and restore the previous zone state within the same maintenance window.

• Export the current zone data before applying any change, so a known-good state exists to restore from.
• If a renewal fails, remove the added record with a corresponding nsupdate delete statement against the same zone and key, then reload the zone on its authoritative servers.
• Re-run the diagnosis commands to confirm the pre-change lookup result has been restored before retrying the affected renewal.

Prevention

Treat CAA coverage as a property of every zone in a hostname’s full CNAME resolution path, not just the apex, and make that check part of routine DNS and certificate change review.

• Add a CNAME-aware CAA check to the change-management checklist for any new customer-facing hostname, consistent with the broader identity, networking and governance controls described in established cloud security benchmarks.
• Run a periodic scan across all customer-facing hostnames that resolves the full CNAME chain and reports any zone in the path without a matching CAA record.
• Require any team that owns a shared delivery or CDN zone used via CNAME to maintain a CAA policy aligned with the customer-facing domains that depend on it.
• Monitor Certificate Transparency logs on an ongoing basis for issuers outside the approved list, as a compensating control for gaps not yet found by configuration review.