# "CAA record prevents issuance": allow your CA in DNS > The CA found a DNS CAA record that does not list it, so it cannot issue. Find the CAA set that applies and add your CA's identifier, such as letsencrypt.org. Source: https://ssl.sh/errors/caa-record-prevents-issuance/ Last updated: 2026-11-10 **This error means the CA checked your domain's DNS CAA records, found a set that does not include it, and is therefore forbidden to issue.** You or your DNS provider published CAA records that allow other CAs only; add the identifier of the CA you are using. ## Quick fix Add your CA to the CAA set that applies to the name, then retry. Look up the CAA set the CA sees. Start with the exact name and walk up: ```bash dig +short CAA www.example.com dig +short CAA example.com ``` The first name that returns records is the one that applies. Add your CA to it and keep the existing entries you still need: ```text example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issuewild "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com" ``` Wait for the old TTL to expire, then retry (use `--dry-run` or staging first). The [CAA checker](https://ssl.sh/tools/caa-checker/) shows the effective set, and the [CAA generator](https://ssl.sh/tools/caa-generator/) builds the records. ## Causes ### 1. CAA lists a different CA You switched from a commercial CA, or a cloud provider, to Let's Encrypt (or the reverse), and the old CAA record allows only the previous CA. - **Confirm:** `dig CAA example.com` shows `issue` values that do not include your CA's identifier. - **Fix:** add an `issue` record for the new CA. Common identifiers: Let's Encrypt `letsencrypt.org`, Google Trust Services `pki.goog`, DigiCert `digicert.com`, Sectigo `sectigo.com`. Check your CA's documentation for others. ### 2. Wildcard blocked by `issuewild` If any `issuewild` record exists, it alone decides wildcard issuance. A common pattern is `issuewild ";"`, which forbids wildcards for all CAs. - **Confirm:** you are requesting `*.example.com` and the set contains `issuewild` records without your CA. - **Fix:** add `0 issuewild "letsencrypt.org"` (or your CA) or remove the restrictive record. ### 3. Inherited from a parent or a CNAME target CAA is looked up on the exact name, then on each parent up to (but not including) the top-level domain. If the name is a CNAME, the CA follows it and checks the target's records too. - **Confirm:** `dig CAA shop.example.com` returns the records of a CNAME target such as a CDN hostname, or empty, while `dig CAA example.com` returns a restrictive set. - **Fix:** add your CA at the level that applies, or publish a separate CAA set directly on the subdomain if your DNS provider allows it next to the CNAME (most do not, so change it at the parent). ### 4. `accounturi` or `validationmethods` mismatch - **Confirm:** the record contains `accounturi=` or `validationmethods=`. - **Fix:** make sure the ACME account URI matches the account your client uses, and that the method you use (`http-01`, `dns-01`, `tls-alpn-01`) is listed. ### 5. CAA lookup fails If the authoritative DNS server returns SERVFAIL or times out on CAA queries, the CA cannot check and will not issue. The error then mentions SERVFAIL or a DNS problem rather than "prevents issuance". - **Fix:** test `dig CAA example.com @ns1.example-dns.com`; fix broken DNSSEC or a DNS server that mishandles the CAA type. ## Fixes by environment The fix is the same on every DNS provider: add an `issue` (or `issuewild`) record that names your CA, then retry the order. **Cloudflare, Route 53, Azure DNS, Google Cloud DNS:** all support CAA records in their DNS editors. Some providers add CAA records automatically when they issue certificates for you; keep those entries when adding your own CA. **Several CAs in use:** list each one with its own `issue` record. A CDN that issues its own certificates needs its CA listed too. **ACME clients:** after fixing DNS, Certbot `certbot renew --dry-run`, acme.sh `--staging`, or cert-manager (delete the failed CertificateRequest so it retries). ## Don't do this - **Delete CAA records without understanding why they exist.** They may protect against mis-issuance; another team may rely on them. - **Retry immediately in a loop.** Cached DNS answers keep failing until the TTL expires, and failed orders count toward [Let's Encrypt rate limits](https://ssl.sh/errors/lets-encrypt-rate-limit/). - **Use a reseller or brand name as the identifier.** Only the domain name the issuing CA documents works; a certificate bought from a reseller is still issued by the underlying CA.