Before issuing a certificate, the CA looked up your domain's CAA records and found that they don't allow it to issue. With Let's Encrypt the message looks like this:
CAA record for example.com prevents issuance
Other CAs word it differently, but it's the same check. Nothing is wrong with your server or your certificate request. The answer is in your DNS.
If your error mentions SERVFAIL or a timeout instead, skip down to the CAA lookup is failing.
Use the name that's actually on the certificate, so shop.example.com rather than example.com if that's what you're requesting.
Or from a terminal:
dig CAA shop.example.com +short dig CAA example.com +short
(More on command-line lookups, including Windows.) The CA uses the first records it finds working up from the exact name, so the closest name that returns anything is the one that matters. Then go through the causes below.
By far the most common one. It usually happens after switching CA, moving to a new host or putting a CDN in front of the site, since the new provider may get its certificates from a different CA to the old one.
Add a record for the CA you're using now:
CAA 0 issue "letsencrypt.org"
Make sure you use the CA's identifier, not its website. Google Trust Services is pki.goog, and ZeroSSL certificates come from Sectigo, so ZeroSSL needs sectigo.com. There's a list of values for each CA.
As soon as there's one issuewild record on the domain, wildcard certificates ignore the issue records completely. So this setup allows Let's Encrypt for www.example.com but nothing at all for *.example.com:
CAA 0 issue "letsencrypt.org" CAA 0 issuewild "digicert.com"
Either add your CA as an issuewild too, or remove the issuewild records so wildcards fall back to issue. Look out for issuewild ";" as well, which blocks wildcards for every CA.
Records on a subdomain replace the parent's. If someone once added CAA records to shop.example.com, the records on example.com don't count for it any more, however many CAs they list.
It works the other way too. A subdomain with no records of its own picks up the parent's, which might be stricter than you expected.
Fix the records on whichever name the CA is actually using, or delete the subdomain's records if you want it to follow the parent again.
If shop.example.com is a CNAME pointing at something like shops.provider.net, the CAA lookup follows it, and any CAA records on shops.provider.net are the ones that apply. You can't edit those.
Check with:
dig CNAME shop.example.com +short dig CAA shops.provider.net +short
Normally the answer is to let the provider issue the certificate, since they'll have allowed their own CA. If you need your own certificate, ask them which CAs they permit, or use a CA that's already on their list.
Things that look fine at a glance but don't work:
www. in the value, like https://letsencrypt.org. It should be the bare identifier.""letsencrypt.org"". Check what dig returns, not what the panel shows.isue or issues. CAs ignore tags they don't recognise, so you end up with no issue record at all.If your record has parameters like these:
CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456" CAA 0 issue "letsencrypt.org; validationmethods=dns-01"
then the request has to come from that ACME account, using that validation method. Moving to a new server or a different ACME client often creates a new account, and a client set up for HTTP validation won't pass a record that only allows dns-01. Update the account number or method, or take the parameter out while you sort it.
If the CA can't get an answer for your CAA records, it refuses rather than guessing. Let's Encrypt reports this as something like:
DNS problem: SERVFAIL looking up CAA for example.com - the domain's nameservers may be malfunctioning
This happens even when you have no CAA records at all, because the CA needs a clean "there aren't any" from your nameservers. The usual causes are:
To narrow it down:
dig CAA example.com dig CAA example.com +cd dig CAA example.com @ns1.your-dns-provider.com
If the first one gives SERVFAIL and the second (which skips DNSSEC checking) works, DNSSEC is the problem. If querying one of your nameservers directly fails or times out, that server is the problem. Try each nameserver listed for your domain.
CAs are allowed to reuse a CAA lookup for up to 8 hours, and your old record may also still be cached for as long as its TTL. If dig now shows the right records, wait a few hours before retrying instead of changing things again.
Post the full error, the exact names on the certificate and the output of dig CAA for each of them on your CA's support site or forum. For Let's Encrypt that's the community forum, where CAA problems come up a lot and usually get answered quickly.