Custom domain Valid Configuration but TLS fails (SEC_E_LOGON_DENIED)

Help
1

My custom domain webshoppages.nl shows “Valid Configuration” in the Vercel dashboard and a certificate was issued (verified via SSL Labs: issued by Google WR1, valid 18 Jun – 16 Sep 2026, trusted, no chain issues). But the domain cannot be reached over HTTPS from any of my computers.

== SYMPTOMS ==

  • All browsers (Chrome, Edge, Brave, also incognito) return ERR_SSL_PROTOCOL_ERROR.
  • curl returns: schannel: next InitializeSecurityContext failed: SEC_E_LOGON_DENIED (0x8009030c). The TLS handshake fails before any data is returned.
  • Happens on 3 separate Windows machines.
  • The site loads fine on mobile over the exact same Wi-Fi.

== KEY EVIDENCE THIS IS NOT A LOCAL / MACHINE ISSUE ==

  • I have another Vercel project, aiseopages.nl, on the SAME Vercel IP (216.198.79.1). On the exact same machine, same browser, same moment, aiseopages.nl opens perfectly over HTTPS — but webshoppages.nl fails the handshake. If this were local antivirus / Schannel / HTTPS-filtering, aiseopages.nl would fail too. It does not.
  • All my other domains became reachable over HTTPS within ~10 hours of setup. webshoppages.nl has been “Valid Configuration” for over 20 hours and still fails — well beyond normal propagation.
  • Vercel support already confirmed their own test servers reach the site with HTTP 200. So the failure is between the edge and European (KPN / EU-Amsterdam) clients.

== EVERYTHING ALREADY VERIFIED / RULED OUT ON MY SIDE ==

  • DNS correct: A record 216.198.79.1, propagated worldwide (checked via dnschecker.org and Google DNS 8.8.8.8).
  • No CAA records (nothing blocking certificate issuance).
  • No proxy configured (netsh winhttp show proxy = direct access).
  • Domain is only in this one Vercel project/account (not duplicated in my other account).
  • GitHub connected correctly. No account warnings.
  • The .vercel.app deployment URL works perfectly.
  • Domain registrar status is Active (not suspended, no pending verification).
  • The registrar (Hostinger) had auto-created its own SSL certificate for the domain — I deleted it, no change.
  • I have NOT pointed nameservers to the registrar; DNS points to Vercel via the A record.
  • Removed and re-added the domain in Vercel — no change.

== REQUEST ==
This looks like a stale or mismatched TLS certificate for this specific domain on the edge serving European (EU/Amsterdam) clients. Could an engineer please re-provision / re-issue the TLS certificate for webshoppages.nl on the edge?

Let’s Debug (letsdebug.net) reports “All OK — no issues found” for webshoppages.nl using HTTP-01. So certificate issuance is not blocked on my side at all — the problem is purely that the edge is not serving the certificate.

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

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.

You can also use v0 to narrow down the possibilities.

3

OPEN THIS POST:
Hi Jack,

Since the certificate exists and the site works from mobile on the same Wi-Fi, I’d separate this into two checks before assuming a general certificate issuance problem.

First, check whether any IPv6/AAAA record is still present somewhere:

dig A webshoppages.nl +short
dig AAAA webshoppages.nl +short
dig CAA webshoppages.nl +short

If AAAA returns anything, remove that stale IPv6 record or test with IPv4 forced. Vercel’s domain troubleshooting docs call out that third-party custom domains should not be pointed to Vercel with AAAA records:

Second, test the TLS handshake with SNI explicitly:

openssl s_client -connect webshoppages.nl:443 -servername webshoppages.nl -brief
openssl s_client -connect 216.198.79.1:443 -servername webshoppages.nl -brief

The -servername webshoppages.nl part matters. A no-SNI scan can show a default/shared edge certificate and may not reflect what browsers actually request for your domain.

If the SNI test fails only from the affected KPN/EU/Windows path but works from mobile or another network, I’d send Vercel support the exact failing timestamp, resolved IP, network/region, and the openssl s_client output. That gives them much better evidence than “Valid Configuration but browser fails.”

4

Thanks Ryu! Results:

dig A → 216.198.79.1 (correct)
dig AAAA → empty (no IPv6 record — already removed earlier)
CAA → none

So no stale AAAA and no CAA. DNS is clean.

For the TLS test on Windows (no openssl/dig, used curl):

  • curl https://webshoppages.nl → fails: schannel SEC_E_LOGON_DENIED (0x8009030c), handshake fails before any cert is returned, even though SNI is sent.
  • This fails identically on 3 machines (mix of Windows 10 and 11), 3 browsers, incognito, antivirus disabled.
  • Crucially: aiseopages.nl on the SAME Vercel IP (216.198.79.1) opens perfectly on the exact same machine/browser. And webshoppages.nl works fine on mobile (same Wi-Fi).
  • Let’s Debug (http-01) reports “All OK — no issues found” for the domain.

Since issuance is fine, no AAAA/CAA, and an identical project on the same IP works from the same machine, this really looks like the edge is not serving the correct certificate for webshoppages.nl specifically on the EU path that serves my connection. Could this be escalated to Vercel staff for a certificate re-provision on the edge?

Greetings

Jack

5

Hi Jack,

Thanks for checking that. Clean A, empty AAAA, no CAA, and a successful Let’s Debug result makes this less likely to be a normal DNS/ACME issue.

The one thing I’d still separate is Windows Schannel vs the actual edge TLS behavior. curl on Windows commonly uses Schannel, so the SEC_E_LOGON_DENIED message may be coming from the Windows TLS stack before you get a normal OpenSSL-style certificate/debug output.

If you can, I’d run these side by side from one affected Windows machine:

curl.exe -Iv --tlsv1.2 https://webshoppages.nl/
curl.exe -Iv --tlsv1.3 https://webshoppages.nl/
curl.exe -Iv --resolve webshoppages.nl:443:216.198.79.1 https://webshoppages.nl/

curl.exe -Iv --tlsv1.2 https://aiseopages.nl/
curl.exe -Iv --tlsv1.3 https://aiseopages.nl/

And, if possible, run this from WSL, Git Bash, or another machine with OpenSSL:

openssl s_client -connect webshoppages.nl:443 -servername webshoppages.nl -showcerts -brief
openssl s_client -connect aiseopages.nl:443 -servername aiseopages.nl -showcerts -brief

The comparison is the important part:

same machine
same network
same time
same Vercel edge IP
one domain works
one domain fails before cert / handshake completes

That is much stronger evidence than just “HTTPS fails,” because it narrows it to domain-specific TLS behavior on a particular client/network path.

I’d also try one non-Windows desktop/laptop on the same Wi-Fi if available. Since mobile works on the same Wi-Fi, the remaining possibilities are either Windows/Schannel-specific behavior or a TLS/edge path that only affects some clients.

At this point I wouldn’t keep removing/re-adding the domain repeatedly. I’d send Vercel support the side-by-side outputs, exact timestamp with timezone, affected ISP/region, and whether the OpenSSL test fails or only Windows Schannel fails. That gives them a much cleaner escalation bundle for checking certificate/edge serving for that hostname.