Let’s Encrypt certificate provisioning fails despite DNS verification succeeding
Hi Netlify Support,
I need help with a TLS/Let’s Encrypt certificate provisioning problem.
Netlify site name: tangerine-meerkat-36eb1d
Custom domain: willscarsales
WWW domain: www.willscarsales
The domain is registered with Porkbun but is using Netlify DNS.
Netlify nameservers:
I’ve completed the normal DNS troubleshooting:
- DNS verification in Netlify: SUCCESSFUL
- DNSSEC: disabled
- AAAA records: none
- CAA records: none
- Both HTTP versions of the domain load the correct Netlify website.
- HTTP response headers for both domains show: Server: Netlify
- Let’s Debug reports: All OK! No issues were found.
However, when I try to provision the Let’s Encrypt certificate, Netlify reports:
“bad dns for custom domain”
and:
“doesn’t appear to be served by Netlify”
The domain was added to Netlify on August 16, 2026, and this problem has now persisted for over two weeks.
DNS verification succeeds, the website is being served by Netlify, and Let’s Debug reports no DNS problems.
Could a support engineer please check the internal ACME/TLS provisioning state for this domain and, if necessary, reset or re-trigger certificate provisioning from your side?
Thank you.
Will — still seeing this live: both willscarsales.co.uk and www fail hostname verify (browser gets the default *.netlify.app cert). That matches “DNS verification SUCCESSFUL / Let’s Debug OK / HTTP served by Netlify” while LE still says “bad dns / doesn’t appear to be served by Netlify.” The panel check and the ACME check are not looking at the same thing.
Usual last-mile on this shape (Netlify DNS + Porkbun registrar, 2+ weeks):
- Apex and www both have to answer from Netlify’s edge on the same site. If one hostname still has a leftover A/ALIAS at Porkbun, or www is a CNAME to the apex while apex is not Netlify, HTTP can look fine and ACME still fails.
- Primary custom domain in the Netlify UI has to be the hostname you are provisioning. A “wrong primary” (common when you added apex + www on different days) leaves LE trying the hostname that is not actually attached.
- After a failed LE attempt, wait out the authorization / rate-limit window before hitting Provision again. Re-clicking the same day usually just burns another failed order.
- Wildcard / leftover SAN: if an old cert or a pending CertOrder still has a stale name, strip it and reissue for apex+www only.
I wrote the operator checklist (decision tree, not “wait on DNS”) here:
https://dual-gate-packet-saas-builders1.vercel.app/ssl/
If you paste the exact error timestamp + whether apex or www is set as primary, the shortest next step is usually #2 or #3, not another Let’s Debug run.