AI AI Tools Guidebook
Troubleshooting

CAA Record Blocks SSL Certificate Issuance

Domain pointed at Vercel / Cloudflare, cert never issues — CAA restricts which CAs can sign.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You bound a custom domain on Vercel / Cloudflare / a new host. DNS is correct, no proxy, but SSL certificate issuance hangs indefinitely. The error in platform logs (if you can see them) mentions something like “CAA record prohibits issuance.” Your domain has a CAA record from a previous CA setup, and that CAA only allows specific certificate authorities to issue. Your new platform uses a different CA, so issuance silently fails. CAA is one of the most obscure DNS troubleshooting causes — most people don’t even know they have CAA records until they trip over this.

Common causes

Ordered by hit rate, highest first.

1. CAA only allows specific CAs

You set CAA records months ago for security (0 issue "letsencrypt.org") — meaning only Let’s Encrypt can issue. Now you’ve moved to a host that uses Google Trust Services or Sectigo. They can’t issue.

How to spot it:

dig CAA yourdomain.com

Examples of restrictive CAA:

0 issue "letsencrypt.org"
0 issue "digicert.com"

If the platform’s CA isn’t listed, issuance is blocked.

2. Host platform uses unexpected CA

Vercel and Cloudflare have moved between Let’s Encrypt, Google Trust Services, Sectigo over the years. Your CAA from 2 years ago may not allow today’s CA.

How to spot it: Platform docs or support tickets often say which CA they currently use. Compare to your CAA.

3. CAA inherited from registrar default

Some registrars (Cloudflare Registrar) set CAA by default. If you didn’t realize it, you might think you have no CAA.

How to spot it: Even if you didn’t set CAA, run dig CAA. If non-empty, registrar set defaults.

4. CAA at parent domain inherits

If example.com has CAA, then app.example.com inherits unless app.example.com has its own CAA. So even setting app.example.com records correctly, the apex’s CAA still applies.

How to spot it:

dig CAA app.example.com
dig CAA example.com

If subdomain has no CAA but apex does, the apex’s CAA applies to the subdomain.

5. CAA with iodef or issuewild only

0 iodef "..." (incident reporting) and 0 issuewild "..." (wildcard issuance only) don’t restrict standard issuance. Confusion about what each field means leads to thinking issuance is fine when it isn’t.

How to spot it: Check the CAA tag (first word after the flag). Only issue controls non-wildcard issuance.

6. Order matters in CAA

CAA records have a flag value (0 = optional, 128 = critical). Critical CAA records block any CA not listed. Misconfigured criticality blocks unexpectedly.

How to spot it: Look at the leading number. 0 is normal; 128 is critical.

Shortest path to fix

Step 1: List existing CAA records

dig CAA yourdomain.com
dig CAA www.yourdomain.com    # subdomain may have its own

Note every issue value.

Step 2: Find what CA your platform uses

Check platform docs:

  • Vercel: typically Let’s Encrypt or Google Trust Services (changes over time)
  • Cloudflare: Let’s Encrypt, Google Trust Services, or proprietary
  • Firebase: Let’s Encrypt
  • Netlify: Let’s Encrypt

If unclear, ask in support: “What CA do you use for SSL on custom domains?”

Step 3: Either add or remove

Option A — Add the platform’s CA:

yourdomain.com    CAA    0 issue "letsencrypt.org"
yourdomain.com    CAA    0 issue "pki.goog"          # Google Trust Services
yourdomain.com    CAA    0 issue "sectigo.com"

Add all the CAs your platform might use, plus your existing ones.

Option B — Remove CAA entirely:

Delete all CAA records. This defaults to “any CA can issue.” Simpler, slightly less secure but fine for most sites.

Step 4: Wait for DNS propagation

CAA records can take up to 24h to propagate fully. Verify:

dig CAA yourdomain.com @8.8.8.8
dig CAA yourdomain.com @1.1.1.1

Both should show the new values.

Step 5: Re-trigger cert issuance

Platform dashboards usually have a “retry” or “remove and re-add” button. Don’t repeatedly remove/re-add; once per hour at most.

Step 6: Verify cert issued

curl -sI https://yourdomain.com | head -3

Should be HTTP/2 200 with valid cert. Or check in browser → click padlock → certificate details.

Prevention

  • Before switching hosts, check what CA they use; update CAA at the same time.
  • Don’t set restrictive CAA unless you have a security reason; default (no CAA) is fine for most sites.
  • For subdomains, set CAA on the apex; subdomains inherit unless overridden.
  • After any CAA change, wait 24h and verify with multiple resolvers before declaring success.
  • Document CAA decisions in your DNS notes so future you knows why CAA exists.

Tags: #Troubleshooting

Related Articles