Pending issuace caa_error

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
Thank you

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 :orange:. As you do not have any CAA records on your own domain the cert should validate just fine.

dig +short caa
0 issue ""
0 issue ""

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

1 Like

As you can see, they are all proxied…

The LWS ones work, the ETA one doesn’t

That subdomain is :orange:, so it is not the exact same setup.

1 Like

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: has no CAA record so it’ll go back one level to which does have CAA records - which don’t allow Cloudflare to issue the certificate.

As your error says, * goes back to which has and 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.

Your *.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:

1 Like

First of all, just want to appreciate your responses!

But, why is my setup working then?

Your certificate for 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 becomes a lookup on - and 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: They generate their own SSL for the front end
Then a back-end api hosted on Digital Ocean: 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?

Thanks you

The DNS entries are currently :grey:. To use the Cloudflare proxy they need to be :orange:. 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 proxy is turned off, but not the eta

@michael I just enabled the proxy on, changed the CNAME to an A (like the article that you shared mentioned, and now I’m getting this error…

A wildcard certificate for * does not match the hostname This is why most wildcard certificates usually have two SANs, one for * and one for

Your cert would cover, but not

You can request a new ACM certificate that includes the required SANs.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.