1. Confirm the destination
Enter the affected hostname in DNS Lookup. Compare A and AAAA with the intended server or CDN. An old IPv6 record can send some visitors elsewhere even when IPv4 is correct. Ask the authoritative nameservers if a recursive answer may be cached.
2. Read the certificate findings
Run SSL Checker for that same hostname. Check the covered names, validity dates, trust result and intermediate chain. A certificate for the bare domain does not automatically cover www. Keep the private key private; it is not needed by this check.
For an Nginx chain, the server certificate is followed by the intermediate certificates in the configured certificate file. Review your certificate provider's full-chain instructions. Back up the affected configuration, test it and reload only after validation passes.
3. Distinguish public and origin TLS
When a CDN proxies the hostname, the public checker usually sees its edge certificate. A valid public certificate does not prove the separate origin connection is healthy. Review the CDN's origin hostname, trust configuration and its own TLS error details.
4. Test every entry URL
Use Redirect Checker for HTTP/HTTPS and the bare/www hostnames. A TLS failure happens before an HTTPS redirect can repair the name. Look for loops and HTTPS-to-HTTP downgrades.
Confirm the change
Repeat the same hostname and URL checks, note their measurement times, then open the site in a browser. This server-side check does not inspect mixed content loaded later by scripts.
Sources
Reviewed by NosHost on 26 October 2026. Nginx HTTPS and certificate-chain guidance · Cloudflare Full (strict).