CAA Wildcard Gap: Why *.example.com Ignores the Base Domain's CA Restriction

Summary

A domain can carry a perfectly valid CAA record restricting issuance to one trusted certificate authority, and still have a wildcard certificate issued by a completely different CA. This isn't a bug in the CAA specification. It's a documented, frequently misunderstood behavior: the issue tag governs non-wildcard names only. Wildcard hostnames are governed exclusively by the issuewild tag, and if that tag is absent, CAs fall back to issue. But if issuewild is present anywhere in the chain and doesn't list a CA, that CA is blocked from issuing wildcards even if issue would have allowed it. The dangerous case runs the other way: an organization sets issue, assumes it covers everything, never sets issuewild, and believes wildcards are locked down when they aren't.

How the Misconfiguration Happens

Most teams adopt CAA after reading a guide that shows a single record like:

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

This looks complete. It restricts standard certificate issuance to Let's Encrypt. But RFC 8659 separates authorization for wildcard certificates from ordinary certificates. Per the spec, a CA evaluating a request for *.example.com must:

1. Look for issuewild records at the domain.
2. If none exist, fall back to issue records.
3. If issuewild exists but doesn't name the requesting CA, refuse the request, even if issue would have permitted it.

So on paper, an issue-only record does extend to wildcards through fallback. The gap shows up in three common variants.

Variant A: inconsistent multi-provider setups. A domain has:

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild "digicert.com"

Whoever added issuewild for an internal DigiCert wildcard cert probably didn't realize it now overrides the issue fallback for all wildcard names. Any other CA, including ones the organization never approved, is still blocked, which looks safe. But if that issuewild record gets deleted later during a provider migration, and the team assumes the issue record "still covers everything," they're right about non-wildcard hosts and wrong about intent-tracking. Nothing enforces that only the originally intended CA can issue wildcards once fallback resumes.

Variant B: subdomain delegation blind spot. A parent zone sets strict CAA, but a delegated subdomain zone, common in multi-team orgs, SaaS platforms issuing tenant subdomains, or CDN CNAME setups, has no CAA records at all. DNS tree-climbing doesn't apply the same way once a zone cut exists with its own SOA. A team spins up *.tenant.example.com under a delegated zone with zero CAA hygiene, and any publicly trusted CA can issue for it.

Variant C: the false sense of completeness. Security teams run a CAA check, see a record exists, mark the control as implemented, and move on. Automated compliance tooling that only checks for the presence of any CAA record, without checking whether issuewild exists or whether it's more permissive than issue, reports green when wildcard issuance is actually unrestricted or restricted to the wrong CA.

The Attack Scenario

Assume example.com has:

example.com.  CAA  0 issue "digicert.com"

No issuewild tag. The organization's internal policy is "only DigiCert issues our certs." Security scanners report CAA as present and compliant.

An attacker who has compromised a weaker link in the domain validation chain, a dangling DNS record, an abandoned cloud storage bucket used for HTTP-01 validation, a hijacked subdomain takeover, or a misissuance by a CA with laxer wildcard controls, requests a certificate for *.example.com from a CA never explicitly authorized for wildcards, say a lesser-known CA with weaker validation practices. Because no issuewild record exists, that CA falls back to issue, sees digicert.com listed, and, if it implements CAA correctly, refuses. The actual exploitation path is subtler and more common than that refusal suggests:

• The attacker targets a CA with a history of CAA validation bugs or misissuance incidents. Multiple CAs have shipped CAA-checking defects that were later disclosed and patched.
• Or the attacker exploits a domain control validation gap that has nothing to do with CAA, for example a DNS-01 challenge against a subdomain the attacker controls via a dangling CNAME. CAA restricts who can issue, not whether domain control was proven correctly, and a CA that never checks CAA at all, or checks it against the wrong label, issues anyway.
• Once issued, the attacker holds a trusted wildcard certificate for *.example.com. That enables on-path or off-path interception, phishing infrastructure presenting as fully valid TLS, or credential-harvesting subdomains (login.example.com, secure.example.com) indistinguishable from production without out-of-band certificate transparency (CT) monitoring.

The cost isn't just the fraudulent certificate. It's incident response scoped to "any subdomain could be impersonated," revocation coordination across every CA in the trust chain, customer-facing disclosure if the certificate was used in active phishing, and reputational damage out of proportion to the cause: a missing tag.

How Validation and Monitoring Catch It

Certificate Transparency logs are the primary detection surface, but only if someone actively monitors them:

• CT log monitoring, through tools like crt.sh, Google's CT search, or a dedicated CT monitoring service, should specifically alert on any certificate, wildcard or not, issued by a CA not present in the domain's issue/issuewild records. Filtering CT alerts against the CAA-authorized CA list turns a noisy feed into a useful one.
• Active CAA record auditing has to check the issuewild/issue distinction explicitly, not just record presence. A proper scanner resolves CAA for both the apex and a simulated wildcard lookup, confirming that issuewild (or issue as fallback) names only approved CAs.
• DNS tree-climbing verification confirms that every delegated subdomain zone either inherits enforceable CAA policy or has its own explicit record. RFC 8659 tree-climbing stops at zone cuts, so a delegated zone with no records isn't silently protected by the parent.
• Periodic diff monitoring on the CAA records themselves matters too, since a single deleted issuewild line during routine DNS maintenance is easy to miss without change alerts.

Mitigation Steps

1. Always pair issue with an explicit issuewild, even if it names the same CA:

example.com.  CAA  0 issue "digicert.com"
example.com.  CAA  0 issuewild "digicert.com"

1. If wildcards are never needed, forbid them explicitly:

example.com.  CAA  0 issuewild ";"

This tells every CA that no wildcard issuance is authorized, closing the fallback gap instead of relying on absence of intent.

1. Set iodef for issuance alerting:

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

1. Apply CAA at every delegated zone, not just the apex. Don't assume tree-climbing protects subdomains behind a separate zone cut.
2. Wire CT log monitoring into the same alerting pipeline as CAA record changes, so a policy change and an unexpected issuance get correlated automatically.
3. Check that compliance tooling validates the tag, not just the record. A scanner that reports "CAA: present" without distinguishing issue from issuewild produces false confidence.

Key Takeaways

• issue does not equal issuewild; wildcard names are a separate authorization scope under RFC 8659.
• The dangerous default is an issue-only record with no issuewild, since the fallback behavior is easy to mistake for protective when it's actually permissive by omission.
• Detection relies on CT log monitoring cross-referenced against the authorized CA list, not on confirming a CAA record merely exists.
• The fix is one DNS record: an explicit issuewild tag, or issuewild ";" if wildcards should never be issued at all.