LEARN. PRACTICE. GROW.Concept and mechanism
HTTPS protects a connection using TLS, with expected-identity verification according to client configuration. It does not prove every internal hop has the same protection. If a proxy terminates TLS and opens another connection, the second hop needs its own analysis. The browser-facing certificate does not validate the upstream. In NGINX, inspect effective verification, name, and trust options: documentation lists proxy_ssl_verify as disabled by default, so writing https in the destination does not establish backend authentication. This lesson uses TLS 1.3 and service-identity principles as a selected foundation rather than teaching complete cryptographic configuration for every environment.
Guided application
For a test before a DNS change, retain the URL hostname and use a bounded resolution override such as curl --resolve. Changing only Host on an IP URL does not ensure the intended TLS identity. If trust fails, investigate the chain, name, and approved authorities; disabling verification hides failure. HSTS in a browser that already knows the policy enforces secure access but does not extend an expired certificate. In a fictional case, upstream migration presents a different certificate name. Correct alignment on that hop and validate the connection; renewing only the public proxy certificate does not address the collected evidence.
A valid browser-proxy hop and invalid proxy-upstream hop are compatible findings: the hops differ.
Common pitfalls
Host instead of SNI and TLS name; -k as a fix; padlock as assurance for every hop; HSTS as renewal.
Related topics: The request and intended representation · Methods, statuses, and controlled retries · Caching, variants, and validation
Establish name, trust, and protection on each relevant connection.
Reference: curl TLS certificate verification · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance