Edge denies TLS (alert 49) for my entire zone — even a fresh hostname on a brand-new project

Help
1

Domain: cardinalleads.xyz (apex + www + any subdomain)
Project: cardinalleads.xyz on team unpacifys-projects-ff8b736a (Hobby)

Every TLS handshake for any hostname ending in cardinalleads.xyz is rejected by the Vercel edge with a fatal access_denied alert (TLS alert 49) before any certificate is presented → browsers show ERR_SSL_PROTOCOL_ERROR. Anyone can reproduce in 30 seconds:

openssl s_client -connect 216.198.79.65:443 -servername cardinalleads.xyz
# → SSL alert number 49 (access denied), no peer certificate available
openssl s_client -connect 216.198.79.65:443 -servername vercel.com
# → valid cert — same edge IP works for other SNIs

Why this is not DNS, not my config, and not an “ISP block”:

  • The alert is generated by the server end of the session (Vercel’s edge) — middleboxes can’t forge in-session TLS alerts, and it reproduces identically from multiple unrelated networks.
  • My other domain on the same team (urbangaleria.xyz) serves a valid cert from the same edge IP.
  • An unknown SNI on a healthy domain (e.g. foo.urbangaleria.xyz) gets a clean close with no alert — only cardinalleads.xyz hostnames get an explicit deny.
  • http://cardinalleads.xyz/ (port 80) returns Vercel’s normal 308→https redirect — the HTTP router knows the domain; only the TLS terminator refuses it.
  • The domain is fully on Vercel nameservers (ns1/ns2.vercel-dns.com, verified ✓✓ in dashboard), verified:true, misconfigured:false, ipStatus:"no-change", apex+www attached to the project (apex → production, www → 308), aliases point at a READY deployment, the .vercel.app URL serves HTTPS 200 fine, and vercel certs ls shows multiple valid unexpired certs incl. a wildcard (CT logs concur). No CAA/AAAA/DNSSEC issues, no registry holds, clean on Spamhaus DBL / SURBL / Google Safe Browsing.

The decisive experiment: I created a brand-new project and attached a never-before-used hostname tlsprobe.cardinalleads.xyz (DNS record auto-created by Vercel managed DNS, attach verified:true). Same fatal alert 49. A fresh hostname on a fresh project can’t have stale config — the deny is keyed to the zone name itself at the edge.

Everything already tried, none fixed it: dashboard refresh · project-level domain remove/re-add · vercel certs issue (succeeds, cert never served) · fresh redeploys · account-level vercel domains rm + re-add · full nameserver migration from external DNS to Vercel-managed DNS · re-attach + verify via REST API · attach to a brand-new project.

Possibly relevant history: the project was renamed from carousels.xyz → cardinalleads.xyz. Notably, SNI carousels.xyz still serves its wildcard cert from the same edge — the OLD name works, the new one is denied.

Support replied that the cert “is valid” (based on a cached third-party checker result from July 12) and suggested ISP blocks — both contradicted by the tests above.

This matches the fingerprint in several unresolved threads (39831, 44207, 35438, 45423, 26114). Could someone from Vercel please have the edge/SSL-frontend team check why the cardinalleads.xyz zone is denied at TLS termination and clear the entry? Happy to provide any further diagnostics.

2

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.

3

Hi copeyeu17-1068,

Your evidence does seem to narrow this down past normal DNS/app debugging. The strongest part is that HTTP reaches Vercel and returns the normal redirect, while the TLS handshake fails before a certificate is served for the cardinalleads.xyz SNI.

I’d package the escalation around the smallest reproducible case, not the full history:

dig NS cardinalleads.xyz +short
dig A cardinalleads.xyz +short
dig CAA cardinalleads.xyz +short

openssl s_client -connect cardinalleads.xyz:443 -servername cardinalleads.xyz -brief
openssl s_client -connect 216.198.79.65:443 -servername cardinalleads.xyz -brief
openssl s_client -connect 216.198.79.65:443 -servername urbangaleria.xyz -brief
curl -I http://cardinalleads.xyz/
curl -I https://cardinalleads.xyz/

If the same Vercel edge IP serves another Vercel hostname but returns alert 49 only for this zone/SNI, that is a much more actionable signal than “SSL is broken.” I’d also include the fresh subdomain test you did, because tlsprobe.cardinalleads.xyz failing on a brand-new project points away from stale project config.

One thing I would not rely on too much is certificate presence in vercel certs ls by itself. It proves a cert exists, but your failure is earlier: the TLS terminator is not selecting/serving it for that SNI. So the useful ask is specifically for someone to check domain/SNI routing or any edge-side deny state for the cardinalleads.xyz zone, not just certificate issuance.

4

Thanks @Ryu — agreed on all points, especially that vercel certs ls only proves issuance, not that the terminator will select/serve the cert for the SNI. Here is your exact command list, re-run fresh today (19 Jul 2026), as the minimal reproducible case:

DNS (all resolving through Vercel’s own nameservers):

dig NS cardinalleads.xyz +short
ns1.vercel-dns.com.
ns2.vercel-dns.com.

dig A cardinalleads.xyz +short
64.29.17.65
216.198.79.65

dig CAA cardinalleads.xyz +short
0 issue "letsencrypt.org"
0 issue "pki.goog"
0 issue "sectigo.com"

TLS — the deny, reproduced via DNS and pinned to a single edge IP:

openssl s_client -connect cardinalleads.xyz:443 -servername cardinalleads.xyz -brief
# Connecting to 64.29.17.65
# SSL routines:ssl3_read_bytes:tlsv1 alert access denied — SSL alert number 49

openssl s_client -connect 216.198.79.65:443 -servername cardinalleads.xyz -brief
# SSL routines:ssl3_read_bytes:tlsv1 alert access denied — SSL alert number 49

openssl s_client -connect 216.198.79.65:443 -servername urbangaleria.xyz -brief
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Peer certificate: CN=urbangaleria.xyz
# Verification: OK

Same edge IP, seconds apart: my other domain on the same team completes a TLSv1.3 handshake with a verified cert; cardinalleads.xyz gets a fatal in-session access_denied before any certificate is presented.

HTTP router knows the domain; only the TLS terminator refuses it:

curl -I http://cardinalleads.xyz/
HTTP/1.0 308 Permanent Redirect
Location: https://cardinalleads.xyz/
server: Vercel

curl -I https://cardinalleads.xyz/
# fails — ERR_SSL_PROTOCOL_ERROR (alert 49)

And the fresh-subdomain control still holds: tlsprobe.cardinalleads.xyz — a never-before-used hostname on a brand-new project, DNS record auto-created by Vercel managed DNS, attach verified:true — gets the identical alert 49 from the same IP. So it’s not stale project config; the deny is keyed to the zone name.

So the specific ask for Vercel staff: please have someone check the domain/SNI routing table or any edge-side deny state for the cardinalleads.xyz zone at the TLS frontend — not certificate issuance (multiple valid unexpired certs exist, including a wildcard). Probe project cardinal-tls-probe is left in place for reproduction. Happy to run any further diagnostics.