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.

https://vercel.com/docs/projects/domains/troubleshooting

You can also use v0 to narrow down the possibilities.

Hi,

A no-sni.vercel-infra.com certificate in a security scan usually means the scanner tested the Vercel edge IP without SNI. That is different from what normal browsers do for a custom domain.

I’d test both cases explicitly:

1
# No SNI / default edge certificate
2
echo | openssl s_client -connect yourdomain.com:443 -brief
3

4
# With SNI / expected custom-domain certificate
5
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief
6

If the first command shows no-sni.vercel-infra.com but the second command shows your actual domain certificate, then the audit finding is probably a no-SNI scanner artifact rather than a user-facing certificate issue.

I’d also check the DNS records:

1
dig A yourdomain.com +short
2
dig AAAA yourdomain.com +short
3
dig CNAME www.yourdomain.com +short
4
dig CAA yourdomain.com +short
5

For third-party domains on Vercel, make sure the A/CNAME records match what Vercel shows in the dashboard, and remove any stale AAAA record if one exists. If CAA records are present, they also need to allow Vercel/Let’s Encrypt to issue the certificate.

Vercel’s domain troubleshooting guide is useful for comparing those checks:

https://vercel.com/docs/domains/troubleshooting

vercel.com

Troubleshooting domains

Learn about common reasons for domain misconfigurations and how to troubleshoot your domain on Vercel.

If browsers fail even when the SNI test passes, the next useful detail would be the exact browser error, affected region/network, and the output of the openssl s_client -servername yourdomain.com command.

Hi Ryu,

Thanks a lot for the precise tests — the side-by-side comparison is conclusive. I ran all of them from one affected Windows machine:

webshoppages.nl:

• curl --tlsv1.2 → SEC_E_LOGON_DENIED (0x8009030c)
• curl --tlsv1.3 → SEC_E_LOGON_DENIED (0x8009030c)
• curl --resolve webshoppages.nl:443:216.198.79.1 → SEC_E_LOGON_DENIED (0x8009030c)

aiseopages.nl (same machine, same network, same Schannel, same minute):

• curl --tlsv1.2 → HTTP/1.1 200 OK (full response, all headers)
• curl --tlsv1.3 → HTTP/1.1 200 OK

So this rules out the two things we wanted to separate:

• It is NOT Windows/Schannel: aiseopages.nl works perfectly through the exact same Schannel stack on the same machine.
• It is NOT a TLS-version mismatch: both 1.2 and 1.3 fail identically for webshoppages.nl.

The handshake for webshoppages.nl fails before completion regardless of TLS version, and even when connecting directly to the Vercel IP (216.198.79.1) with SNI. Meanwhile aiseopages.nl on that exact same IP returns 200 OK.

Summary of the isolation:

• same machine, same network, same time, same Vercel edge IP (216.198.79.1)
• one domain (aiseopages.nl) works
• the other (webshoppages.nl) fails before the cert/handshake completes

Earlier checks already confirmed: clean A record, empty AAAA, no CAA, no _acme-challenge, and Let's Debug (http-01) returns "All OK". The .vercel.app deployment works fine, and the domain also loads on mobile over the same Wi-Fi.

This really isolates it to domain-specific TLS/edge serving for webshoppages.nl on the EU path that serves my connection. Could this be escalated to Vercel staff to re-provision / re-issue the certificate for this hostname on the edge?

I'm happy to provide privately: project ID, deployment ID, exact failing timestamp (CEST), ISP/region (KPN, Netherlands), and any log/generation IDs.

Thanks again for the help narrowing this down. Jack

Project: webshoppages (Hobby) — Domain: webshoppages.nl