I’m part of the LeadToScope team. We’re investigating a TLS failure on www.leadtoscope.com, including /contractors, and would appreciate help identifying the failing connection path.

On October 30, 2026 at 21:19:17 UTC, an HTTPS request with certificate verification and hostname checking enabled failed with WRONG_VERSION_NUMBER before an HTTP response. Chrome also showed ERR_SSL_PROTOCOL_ERROR.

At 21:33:20 UTC, one ClientHello-only check received five initial bytes, ffffffffff, rather than a recognizable TLS record header. At 23:18:08 UTC, a controlled same-network pair against 216.198.79.1, using each owned hostname as SNI, failed with WRONG_VERSION_NUMBER for both www.leadtoscope.com and leadtoscope.com. A certificate-verifying TLS attempt to Vercel’s other recommended address, 64.29.17.1, also failed earlier. No DNS or network settings were changed.

The domain page shows Valid Configuration, and provider certificate records are unexpired. SSLShopper reports a matching, trusted certificate expiring January 11, 2027, but exposes no assessment timestamp; its results may be cached for a day.

Vercel’s support AI reports a homepage HTTPS 200 at 22:42:05.726 UTC. We have its statement, not an independent raw response receipt. Our account owner also reports an SSL error on an independent connection to /contractors; the exact error code, device, network and observation time are unknown.

What supported read-only observation would distinguish a custom-host delivery issue from a response introduced elsewhere along the path? We haven’t identified a component to repair. We’re seeking a diagnostic method before changing configuration, using public TLS facts only.

Written with AI assistance; reviewed by our team.