Quick fix
Inventory every CA and ACME account used for the domain and its subdomains.
What this finding means
SecuTest evaluates whether a syntactically valid policy meaningfully restricts normal and wildcard issuance. CAA is a defense-in-depth control and should be paired with certificate-transparency monitoring.
Interpretation boundary
Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, or business intent when those cannot be proven remotely.
Why it matters
Security impact
An absent or overly broad CAA policy gives 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 that requests certificates.
Remediation procedure
- Inventory every CA and ACME account used for the domain and its subdomains.
- Publish issue records only for required authorities.
- Publish issuewild separately when wildcard issuance requirements differ.
- Add an iodef contact where operationally supported.
Commands and configuration examples
Replace example values with the hostname, selector, IP address, port, or provider values shown in your SecuTest evidence.
dig +short CAA example.comopenssl s_client -connect example.com:443 -servername example.com </dev/nullVerify the fix
- Run: dig +short CAA example.com
- Test normal and wildcard renewal paths.
- Review certificate transparency after deployment.
- Repeat the SecuTest scan.
Confirm the externally visible result
Re-scan your domain
After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.
Common mistakes
- Authorizing a CA that is no longer used.
- Omitting issuewild when wildcard issuance must be restricted.
- Deploying CAA without testing renewal automation.