CAA vs CT Issuance

CAA Record Presence (in DNS Security) verifies that you publish CAA records at all. This check goes one step further: it cross-references your published CAA policy against actual certificate issuance history in CT logs over the last 12 months. If a CA you have not authorized has issued certs for your domain, this check finds it. The combination is the only public signal that confirms CAA is actually working as intended.

How the check works

Per scan, RedScore reads your published CAA records, parses the authorized CA domains from issue / issuewild directives, then walks every CT-logged cert from the last 12 months. For each cert, it checks whether the issuing CA matches an authorized entry. Unauthorized issuances are bucketed by recency (within 6 months vs older). Scoring:

• CAA not published: ~0.33 (5/15). Reason: caa_not_configured. The check cannot evaluate compliance because there is no policy to check against.
• CAA published, no unauthorized issuances: 1.0 pass.
• Historical mismatch only (older than 6 months): 0.76 (warn). Reason: historical_caa_mismatch. Likely predates your current CAA configuration.
• Recent unauthorized issuance (within 6 months): 0.20 (fail). Reason: recent_caa_violation. CA noncompliance or unauthorized procurement.
• 5 or more unauthorized total: 0.0 (fail). Reason: widespread_caa_noncompliance. Major procurement gap or systemic CA noncompliance.

How the verdict maps to evidence

• Pass: CAA published, no unauthorized CAs found in CT history.
• Warn: historical mismatch (older certs from CAs no longer authorized).
• Fail: recent unauthorized issuance, or widespread noncompliance, or no CAA published at all.

Evidence shows the parsed caa_allowed_domains, the unauthorized_certificate_hits list (with issuer name and not_before_recent flag for each), certificates_in_window, and CT data source.

Special states

• Reduced confidence (when caa_not_configured): the check still scores but with explicit acknowledgment that compliance cannot be evaluated against a missing policy. Evidence includes active_tls_issuer_samples so you can see what is actually being served.

Fix by reason code

caa_not_configured

Publish CAA records first. The CAA Record Presence guide in DNS Security walks through the format and per-provider setup. Once CAA is published, this check can actually evaluate your policy compliance and the score moves automatically.

historical_caa_mismatch (warn)

Old certs in CT history were issued by CAs that are not in your current CAA list. Two interpretations:

• Pre-CAA issuance: certs were issued before you published CAA. They will roll off the 12-month CT window naturally; no action needed beyond confirming the unauthorized CAs are no longer in use.
• Forgotten authorized CA: a CA you actually do use is not in your CAA list. Either add it (if you intend to keep using it) or stop using it (if you have moved on). Re-issue affected certs from a listed CA.

recent_caa_violation (fail)

An unauthorized CA issued a cert for your domain within the last 6 months despite your CAA records being in place. Investigate immediately:

• Which CA issued the cert? unauthorized_certificate_hits in evidence shows the issuer name.
• Who requested it? If it is a legitimate team using a CA outside policy, update CAA to include them or get them onto an approved CA.
• Could it be a CA noncompliance issue? CAs are required by Baseline Requirements to honor CAA. A real violation is rare but worth reporting to the CA's compliance team.
• Could it be an unauthorized procurement? Someone with control of your DNS or domain account requested a cert outside policy. Audit who has cert-issuance access.
• Is it a phishing or impersonation attempt? In rare cases, attackers obtain certs via DCV bypass. CT log monitoring (Cert Spotter, Hardenize, internal CT watcher) catches these in real time.

widespread_caa_noncompliance (fail)

5 or more unauthorized issuances in 12 months. Either many CAs are ignoring your CAA (very rare), or your procurement is fragmented across many CAs without your CAA reflecting reality, or your CAA list is too restrictive. Audit:

• Compare unauthorized_certificate_hits to your actual issuance pipeline: are these legitimate certs from CAs you use but did not list?
• If yes, expand CAA to cover legitimate CAs (and consolidate per the Issuer Diversity guide).
• If no, you have a procurement governance problem. Centralize cert issuance and revoke any unsanctioned active certs.

Stronger CAA: account-binding extensions

Standard CAA only restricts which CA can issue. The accounturi parameter (and validationmethods) let you restrict to a specific account at that CA, preventing other accounts from issuing for your domain even if they are at the same CA. Useful when you operate at scale and want belt-and-braces protection:

yourdomain.tld.   IN  CAA  0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345; validationmethods=dns-01,http-01"

Not every CA supports the accounturi or validationmethods extensions. Check the CA's docs before adding (Let's Encrypt, BuyPass, Sectigo, and SSL.com are commonly supported).

Verify the fix

• Walk unauthorized_certificate_hits in the evidence. For each entry, confirm whether the CA was authorized at the time of issuance.
• After updating CAA, run dig CAA yourdomain.tld to confirm the new policy is published.
• After re-issuing affected certs, watch the next scan: the percentage of unauthorized hits should drop as new compliant certs replace old ones in the rolling 12-month window.
• Re-run the RedScore lookup. The CAA cross-reference recomputes against the new policy.

Common pitfalls

• Removing a CA from CAA without updating issuance pipelines. Everything continues to renew as before; new certs from the now-unauthorized CA show up as recent_caa_violation immediately. Migrate the pipeline first, then tighten CAA.
• CAA on apex but checked-against-cert is for a subdomain. CAs check CAA at the cert hostname, walking up. Make sure your apex CAA covers what subdomain certs need; or publish per-subdomain CAA where needed.
• Wildcard cert issuance failing because issuewild is missing. If your apex says issue but not issuewild, wildcard issuance is implicitly allowed for the same CA. Adding issuewild explicitly with a different CA changes that. Audit before publishing issuewild.
• CDN-issued certs counted as unauthorized. Cloudflare, CloudFront, and Fastly issue certs under their own CA org names; they may not match an entry in your CAA if you only listed your own CAs. Either add them to CAA explicitly or accept that proxied hostnames will show as unauthorized in this check.
• Old commercial CA still in business but no longer listed. The historical_caa_mismatch warn persists until the old certs age out. Wait it out or revoke and re-issue.
• False sense of security from CAA alone. CAA prevents accidental issuance from compliant CAs. It does NOT prevent issuance from CAs that ignore CAA, nor from compromised accounts at authorized CAs. Pair with CT-log monitoring for real detection.