I’m trying to setup a new certificate like i’ve done the preivious ones a couple of months ago and i’m getting a Pending Issuance error .
Please see the screenshot for details.
BTW, i tried TXT verification before trying email, just as another resort to see if that would fix it… both option throw the same error.
DNS is being handled by Cloudflare. Proxy status is enabled
I’d appreciate any help I can get
You have a CNAME for the
eta subdomain to Vercel, and they have their own CAA records there.
If I assume you plan to have this subdomain proxied, and the name suggests it is a non-production environment, change to . As you do not have any CAA records on your own domain the cert should validate just fine.
dig +short caa eta.dev.grimsyndicate.com
0 issue "letsencrypt.org"
0 issue "globalsign.com"
The certificate i’m trying to create is on the *.eta wildcard though.
I have the same setup working with the *.lws subdomain
And lws subdomain also has a CNAME to Vercel, and it’s working just fine
As you can see, they are all proxied…
The LWS ones work, the ETA one doesn’t
That subdomain is , so it is not the exact same setup.
I just posted another screenshot showing they are all proxied… almost same time as yours, just want to make sure you didn’t miss that
CNAMES are also setup the same way:
api.eta.dev.grimsyndicate.com has no CAA record so it’ll go back one level to
eta.dev.grimsyndicate.com which does have CAA records - which don’t allow Cloudflare to issue the certificate.
As your error says,
*.eta.dev.grimsyndicate.com goes back to
cname.vercel-dns.com which has
letsencrypt.org as the only ‘allowed’ certificate authorities in the CAA records.
This isn’t an issue on proxied domains since as a byproduct of proxying, that CNAME turns into Cloudflare IPs meaning that recursive lookups don’t ‘follow’ your CNAME to find the CAA records of Vercel.
*.dev records aren’t proxied, will follow the CNAME root & will hit CAA records that don’t allow Cloudflare to issue a certificate - this is fully expected behaviour.
I think the OP is also saying that they have an identical setup on another domain, and that works with the cert visible here:
First of all, just want to appreciate your responses!
But, why is my
api.lws.dev.grimsyndicate.com setup working then?
Your certificate for
lws.dev.grimsyndicate.com was issued on the 23rd of February.
Not Before: Feb 23 00:00:00 2022 GMT
Not After : Feb 23 23:59:59 2023 GMT
DNS history for your domain shows that your record was proxied on that day.
It’s likely that you proxied the domain, which removed the CNAME, and therefore allowed certificate issuance.
Cloudflare’s proxy answers DNS queries with their own IP addresses so that traffic hits Cloudflare - since your CNAME is no-longer present, resolvers will no-longer follow the CNAME chain. If they did see the CNAME and follow it, they’d reach Vercel’s CAA records.
If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.
A lookup on
lws.dev.grimsyndicate.com becomes a lookup on
cname.vercel-dns.com - and
cname.vercel-dns.com returns the CAA records that are preventing issuance.
I’ll be honest with you… this is going a bit over my head…
I’m trying to solve this scenario.
I have a front-end site hosted on Vercel:
eta.dev.grimsyndicate.com. They generate their own SSL for the front end
Then a back-end api hosted on Digital Ocean:
api.eta.dev.grimsyndicate.com. I have my own SSL generated by LetsEncrypt
How can I have everything proxied and fully encrypted through Cloudflare?
@KianNH @michael do you have any recommendations on how I can solve the above?
The DNS entries are currently . To use the Cloudflare proxy they need to be . But this is not what Vercel recommend. But other people on the Community have far more experience using Vercel and Cloudflare together.
Yeah, the problem is that CNAME proxy doesn’t work with subdomains more than 1 level deep… I’ll see if I can find the documentation where I saw that, but that was the case 3 months ago when I created the lws setup
Can’t remember if it was specifically for CNAME, or what… but that’s why only the
eta.dev proxy is turned off, but not the
@michael I just enabled the proxy on
eta.dev.grimsyndicate.com, changed the CNAME to an A (like the article that you shared mentioned, and now I’m getting this error…
A wildcard certificate for
*.example.com does not match the hostname
example.com. This is why most wildcard certificates usually have two SANs, one for
*.example.com and one for
Your cert would cover
blah.eta.dev.grimsyndicate.com, but not
You can request a new ACM certificate that includes the required SANs.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.