caa.policy Reviewed July 2026

Quick fix

Inventory every CA and ACME account used for the domain and subdomains.

What this finding means

SecuTest evaluates whether a valid policy meaningfully restricts normal and wildcard issuance. CAA is defense in depth: it narrows authorized issuers but does not prevent abuse of an authorized CA account or replace certificate-transparency monitoring.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Unauthorized or unexpected certificate issuance

How the attack or failure scenario works

An attacker who can pass domain-control validation may seek a certificate for the victim domain. CAA tells compliant public CAs which issuers are allowed. Without a restrictive policy, any trusted CA may proceed if its other validation succeeds.

Conditions and limitations

  • The attacker can satisfy or subvert a CA's domain-control validation.
  • No restrictive inherited CAA policy blocks the selected CA.
  • The certificate is then used with DNS, routing, proxy, or endpoint control to impersonate the service.

Why it matters

Security and business impact An absent or overly broad CAA policy provides no DNS-level restriction on which certificate authorities may issue for the domain.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for CAA policy.
  • The certificate automation, ACME account, CDN, load balancer, or reverse proxy requesting certificates.

Remediation procedure

  1. Inventory every CA and ACME account used for the domain and subdomains.
  2. Publish `issue` records only for required authorities.
  3. Publish `issuewild` separately when wildcard issuance requirements differ.
  4. Enable certificate-transparency monitoring and maintain an emergency revocation process.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Restrict normal issuance
example.com. 3600 IN CAA 0 issue "letsencrypt.org"

Deny wildcard issuance
example.com. 3600 IN CAA 0 issuewild ";"

Incident contact
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

Verify the fix

  1. Run `dig +short CAA example.com` and inspect inherited parent policy.
  2. Test normal and wildcard renewal automation.
  3. Review certificate-transparency logs for unexpected issuers.
  4. Repeat the scan after DNS propagation.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Authorizing a CA that is no longer used.
  • Omitting `issuewild` when wildcard policy should differ.
  • Deploying CAA without testing renewal automation.

Authoritative references