SSL Certificate CAA Record Errors: How to Fix

SSL certificate issuance errors caused by CAA (Certificate Authority Authorization) records happen when your DNS has a CAA record that does not explicitly permit the certificate authority (CA) you are trying to use, or when the CA cannot read the record at all. The fix is to either add the correct CA to your existing CAA record, remove the restrictive CAA record, or wait for DNS propagation after making the change. This article explains what CAA records are, why they block issuance, and the exact steps to resolve the most common errors.

What Is a CAA Record and Why Does It Matter?

A CAA record is a DNS resource record that tells certificate authorities which CAs are allowed to issue SSL/TLS certificates for your domain. It was standardized in RFC 6844 and is now enforced by all major CAs. When you request a certificate, the CA queries your domain’s DNS for a CAA record. If the record exists and does not list that CA, the CA must refuse to issue the certificate. If the DNS query fails (e.g., because the record is malformed or the DNS server is unreachable), the CA will also refuse, because it cannot verify permission.

CAA records are optional, but once you add one, it becomes a hard requirement. This means a single misconfigured CAA record can break issuance for all CAs, even if you previously had no issues.

Common CAA-Related Issuance Errors

Here are the most frequent errors you will see when trying to get an SSL certificate, and what they usually mean:

• “CAA record forbids issuance” – The CA you are using is not listed in the CAA record. For example, if your record only allows Let’s Encrypt but you are trying to get a certificate from DigiCert, this error appears.
• “CAA record retrieval failed” – The CA could not fetch your CAA record at all. This often happens due to DNS propagation delays, a typo in the record name, or a DNS server that does not support CAA queries.
• “CAA issue policy violated” – The CAA record uses the issue tag but with a value that does not match the CA’s domain. For instance, issue "comodo.com" will not allow Sectigo, even though they are related.
• “CAA issuewild” restriction – If you have an issuewild tag that does not include the CA, wildcard certificate issuance will fail even if the base domain is allowed.

How to Check Your Current CAA Records

Before making any changes, you need to see what CAA records exist for your domain. You can do this with a simple command-line tool or an online DNS lookup. On most systems, the dig command works:

dig CAA example.com

If you do not have dig, use an online DNS lookup tool. Look for lines that start with example.com. IN CAA. If you see nothing, you have no CAA record – that is fine and should not cause errors. If you see one or more, note the exact tags and values. Common tags are issue (for standard certificates), issuewild (for wildcard certificates), and iodef (for reporting, not blocking).

Step-by-Step Fix for CAA Issuance Errors

Once you have identified the problem, follow these steps to fix it. The exact menu names depend on your DNS provider, but the logic is universal.

1. Log in to your DNS management console – This is usually at your domain registrar or hosting provider (e.g., Cloudflare, GoDaddy, AWS Route 53).
2. Find the DNS records section – Look for “DNS Management”, “Zone Editor”, or “DNS Records”.
3. Locate the existing CAA record – If you have one, click edit. If you do not have one, you will need to add a new record.
4. Add the correct CA to the record – The value must be the CA’s domain exactly as they specify. For example, for Let’s Encrypt, use letsencrypt.org. For DigiCert, use digicert.com. You can have multiple CAA records, each listing a different CA. Do not use wildcards or partial domains.
5. If you have an issuewild tag, update it too – Wildcard certificates require a separate tag. If you do not need wildcards, you can remove the issuewild tag entirely.
6. Save the record and wait for propagation – DNS changes can take from a few minutes to 48 hours. Most providers update within an hour, but CAs may cache the old record for up to 8 hours. Retry your certificate issuance after a few hours.
7. If the error persists, remove the CAA record temporarily – Delete all CAA records, wait for propagation, and try issuance again. If it succeeds, you know the CAA record was the problem. Then add it back with the correct values.

Misconception: CAA Records Are Optional, So Why Do They Break Things?

Many people assume that because CAA is optional, a misconfigured record should be ignored. That is not how CAs work. The moment a CAA record exists, it is authoritative. The CA must check it and obey it. There is no “best effort” – if the record says no, the CA says no. This is why a single typo (like comodoca.com instead of comodo.com) can block issuance for days while you debug.

Another common misconception is that CAA records apply to the subdomain only. In reality, CAA records are inherited by subdomains unless a more specific record exists. So a CAA record on example.com also applies to www.example.com and api.example.com. If you have a restrictive record on the root domain, it will block certificates for all subdomains.

How to Avoid Future CAA Errors

Prevention is simpler than debugging. Here are practical habits to keep:

• Always list all CAs you might use – If you have multiple servers or services, list all of them. You can have up to 1024 characters per record, so there is room.
• Use the issue tag for standard certs and issuewild only if you need wildcards – If you do not need wildcards, do not add issuewild at all. An empty issuewild tag (with no value) blocks all wildcard issuance, which is a common mistake.
• Test after any DNS change – Use a DNS lookup tool to verify the record is visible before requesting a certificate.
• Set a reminder to check CAA when switching CAs – If you move from one CA to another, update the CAA record before you start the new issuance.

What If the Error Is Not CAA-Related?

If you have removed all CAA records and still get issuance errors, the problem is likely elsewhere. Common culprits include:

• DNS validation failure – The CA cannot find the TXT record you created for domain validation. Check that the record name is exactly _acme-challenge.example.com and that it is not a CNAME pointing elsewhere.
• HTTP validation failure – The CA cannot reach the file you placed on your web server. Check that port 80 is open and the file is accessible at the exact URL.
• Rate limits – Some CAs limit how many certificates you can issue per week. If you hit the limit, you will see a different error message.
• Private key mismatch – If you are renewing and the CSR does not match the private key, issuance fails.

In those cases, the fix is not DNS but server configuration. Check your web server logs and the CA’s error message for more clues.

Frequently Asked Questions

How long does it take for a CAA record change to take effect?

DNS propagation typically takes 1–48 hours, but most providers update within an hour. CAs may cache the old CAA record for up to 8 hours, so if you just changed it, wait at least 8 hours before retrying. You can check propagation with a global DNS checker.

Can I have multiple CAA records for the same domain?

Yes. You can have multiple CAA records, each listing a different CA. The CA will check if its own domain appears in any of them. If it does, issuance proceeds. If none match, it is denied.

What does the CAA tag “iodef” do?

The iodef tag specifies a URL where CAs should send reports about certificate issuance requests. It does not block or allow anything. It is used for monitoring and is optional. It will not cause issuance errors.

Do I need a CAA record for a wildcard certificate?

Yes, if you have any CAA record, you need either an issue tag for the wildcard domain or a separate issuewild tag. If issuewild is present but does not list your CA, wildcard issuance fails. If issuewild is absent, the issue tag applies to wildcards as well.

My DNS provider does not support CAA records. What should I do?

If your provider does not support CAA records, you cannot have one, so you will not get a CAA error. However, if you previously used a provider that did support CAA and you moved away, the old record may still exist in the old zone. You must delete it there. If you are on a provider without CAA support, you are fine – no record means no restriction.

Can a CAA record block a certificate for a subdomain even if the subdomain has its own CAA record?

Yes, but only if the subdomain’s CAA record does not include the CA. CAA records are inherited from the parent domain unless the subdomain has its own record. If the subdomain has its own record, that record takes precedence for that subdomain. So if the subdomain’s record allows the CA, issuance proceeds even if the parent’s record does not.

Related

• Best Coding Games: Top Picks & Buying Guide
• Fairy Tail Wizard Chronicle Code Not Working: Fixes
• Headphones Plugged In But Sound From Speakers? Fix