Error guide / CAA record prevents certificate issuance
CAA record prevents certificate issuance
A CAA record is a DNS record that names which certificate authorities are allowed to issue certificates for your domain. When your CA reports "CAA record prevents issuance" or "no valid CAA record found", it looked that record up, did not find itself on the list, and stopped by policy rather than because anything is broken. You see this at issuance or renewal time: in certbot or acme.sh output, in a hosting panel's AutoSSL log, or on a commercial CA's validation screen. Visitors never see the message itself, only the expired or missing certificate later on.
Check your site
What causes it
Most often the domain already carries a CAA record naming a different authority, left behind by a previous host or an old certificate vendor, and the CA you use today is simply not on the list. Next most common is a wrong value: it must be the CA's exact documented identifier, for example letsencrypt.org, and lestencrypt.org or https://letsencrypt.org blocks issuance just as effectively as a deliberate restriction. Third is a wildcard mismatch, where the domain permits issue but carries a separate issuewild line, so only requests for *.example.com fail. Less often the record is inherited: the subdomain has no CAA of its own, the apex record governs it, and people end up editing the wrong name.
How to fix it
- Run the check on this page for the exact hostname the certificate is for and read the CAA lines. Nothing listed means the domain publishes no CAA at all, any CA may issue, and the refusal has another cause, so re-read the CA's error text. If lines are listed, each shows flags (normally 0), a tag and a value, and that value list is exactly what your CA compared itself against. If instead the CA says the CAA lookup itself failed (SERVFAIL), the fault is in your DNS servers or DNSSEC, not in the record's contents.
- If the hostname shows no CAA of its own, run the check again on the bare domain (example.com, not www.example.com). CAA is read at the exact name first and then up the tree toward the apex, so an apex record governs every subdomain that does not publish its own.
- Compare each issue value with the identifier your CA documents: letsencrypt.org for Let's Encrypt, pki.goog for Google Trust Services, sectigo.com, digicert.com and so on. It has to be the bare identifier, with no https://, no trailing slash and no stray spaces. An iodef line is only an address for violation reports, it blocks nothing, so leave it in place.
- If you are requesting a wildcard, look specifically for issuewild. When an issuewild line exists, wildcard requests are judged by it alone and the issue lines are ignored for that request; when there is no issuewild at all, issue covers wildcards too. A value of a single semicolon (;) means no authority may issue.
- Fix the record where the DNS zone actually lives (registrar, hosting control panel, or Cloudflare): add or edit a CAA record with flags 0, tag issue, and the value set to your CA's identifier, keeping lines for any other CA you still use. Deleting every CAA record is also valid and returns the domain to the default, where any authority may issue.
- Re-run the check until the new values appear, and only then retry issuance. DNS caching means the fix is not instant: allow at least the record's TTL, and remember that a CA may reuse a recent CAA lookup for up to 8 hours, so an immediate retry can still hit the old answer.