How to verify HTTPS, HSTS, and TLS settings

curl -sSI http://example.com

Look for a 301, 302, 307, or 308 response with a Location value using https:// and the expected hostname. A redirect from an application while a CDN or proxy is configured differently can produce a misleading result.

curl -sSI https://example.com | grep -i strict-transport-security

Confirm the header is present on the HTTPS response and record its max-age and optional directives. HSTS is a browser instruction; its presence does not prove every subdomain is ready for includeSubDomains or preload.

openssl s_client -connect example.com:443 -tls1 -servername example.com < /dev/null
openssl s_client -connect example.com:443 -tls1_1 -servername example.com < /dev/null

A rejected handshake is the desired outcome for TLS 1.0 and 1.1. Run the test against the public edge and interpret the exit output with the negotiated protocol, certificate, and proxy path in mind.

• A redirect works for the apex but not for a www or application subdomain.
• HSTS appears in a cached response, but not at the public edge or on every covered hostname.
• Cloudflare’s dashboard setting is correct while DNS is not authoritative for the hostname being tested.
• A reverse proxy terminates TLS before the origin, so an origin-only test does not describe visitor behavior.
• A scanner follows redirects and reports only the final HTTPS response, hiding that the HTTP upgrade was absent.

Record the hostname, timestamp, response values, and tested edge. These checks describe a point-in-time observation; they do not certify compliance, prove a website is secure, or replace a penetration test. The free Public Snapshot is read-only, one-time, retained for seven days, and does not enable recurring monitoring.