Hi — I have a persistent custom-domain issue on a Hobby project that I can’t resolve from my side (and SSL support isn’t available on Hobby), so posting here.
Symptom — the certificate exists but the edge never serves it:
Dashboard shows “Valid Configuration” and SSL certificates are issued (visible in the dashboard and in Certificate Transparency logs — Let’s Encrypt, valid until Sep 2026, including a fresh *.e-pindych.ru wildcard).
But a TLS handshake to e-pindych.ruandwww.e-pindych.ru returns no peer certificate for the SNI (SSL handshake has read 0 bytes).
Port 80 returns an empty reply.
The same edge IP 216.198.79.1 serves *.vercel.app certificates correctly — so the edge is up, it just doesn’t have this hostname bound.
Reproduced from multiple independent networks worldwide (not a local DNS/cache issue).
What I’ve tried (no effect):
Waited many hours / overnight.
Removed and re-added the domain several times.
Redeployed production (fresh build).
Migrated the domain to Vercel nameservers (ns1/ns2.vercel-dns.com). Dashboard now shows “Nameservers: Vercel” and Vercel issued a fresh *.e-pindych.ru wildcard cert ~1h later — but 4+ hours later the edge still serves no certificate.
Everything verifiable looks correct:
DNS: apex and * ALIAS → Vercel; A resolves to 216.198.79.1.
CAA allows letsencrypt.org (plus pki.goog, sectigo.com); no AAAA; no DNSSEC.
This looks like an edge / domain-binding issue on Vercel’s infrastructure: the certificate is issued but the serving layer never binds the hostname. Could someone from Vercel re-trigger / fix the edge binding for this domain? Happy to share project/domain IDs. Thanks!
The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points.
You can also use v0 to narrow down the possibilities.
Given that the dashboard shows valid configuration and you’re seeing the certificate in CT logs, I’d stop focusing on redeploys/app code and try to prove whether the hostname is actually bound at Vercel’s serving layer.
These checks are useful because they bypass a lot of “maybe DNS propagation” uncertainty:
If the DNS checks still show Vercel nameservers, no unexpected AAAA, and the expected CAA, but the --resolve / openssl s_client tests still return no peer certificate for the correct SNI, that mostly rules out local DNS and registrar-side propagation.
One more thing I’d verify in the project Domains page: make sure the exact hostnames being tested are added to the same project, not just covered by a wildcard certificate. I’d want all intended entries present explicitly while debugging:
e-pindych.ru
www.e-pindych.ru
*.e-pindych.ru # only if you actually need wildcard tenants
If those are all present and valid, then your diagnosis sounds reasonable: certificate issuance succeeded, but the edge hostname binding/cert deployment for those hostnames may not be serving correctly. At that point the best evidence for staff is the openssl s_client output plus the DNS command outputs above, with any project/team IDs removed if you do not want them public.