HTTP vs HTTPS explained simply

HTTP vs HTTPS explained simply

When a user types a web address the browser usually chooses HTTP or HTTPS as the protocol to fetch content, where HTTP is plain text and HTTPS is HTTP over a secure transport layer called TLS, sometimes still referred to by the older name SSL. HTTPS provides encryption so that eavesdroppers cannot read the data in transit, integrity so that intermediaries cannot silently alter content, and server authentication through certificates so the client can verify it is talking to the intended host. For an infrastructure engineer this distinction matters because apparent connectivity problems may be protocol related rather than application related, and the troubleshooting steps differ depending on whether TLS is involved.

Troubleshooting HTTPS issues starts by recognising common symptoms and reading browser error messages carefully because they guide the diagnosis. Typical symptoms include a red padlock or warning page when loading a site, resources that fail to load because they are delivered over HTTP while the page is HTTPS (mixed content), slow or failing handshakes, and redirect loops where HTTP redirects to HTTPS and back again. Server logs, reverse-proxy logs and browser developer tools are essential to collect concrete error codes, TLS alert names, and HTTP status codes before making any changes.

• Check the certificate expiry date and the certificate chain completeness.
• Verify the certificate name matches the requested hostname and that SNI is configured when needed.
• Confirm that the server presents the full chain including intermediates and that OCSP stapling is behaving as expected.
• Test TLS compatibility by checking supported protocol versions and cipher suites to ensure client compatibility.
• Examine redirect rules and HSTS settings to avoid redirect loops or forced HTTPS errors.
• Use client tools such as curl with verbose output or openssl s_client to inspect the handshake and certificate chain.

Start a hands-on investigation with the client and server perspectives in parallel to narrow the fault. On the client side open the browser error page or developer console and note the exact message and the response headers, which can show HSTS or Strict-Transport-Security values. On the server side use verbose tools; for example curl -I -v against the HTTPS endpoint to see the response headers and TLS handshake, and openssl s_client -connect host:443 -servername host to reveal the certificate chain and any handshake issues. A name mismatch, an expired certificate, or an incomplete chain are the most frequent causes that are quick to fix once identified.

Many HTTPS problems come from configuration layers in modern deployments such as load balancers, CDN edges, or reverse proxies, so it is important to identify where TLS termination occurs. If TLS is terminated on a load balancer but the backend server expects to see the original host header or perform redirects, misconfiguration can produce unwanted behaviour such as redirect loops or incorrect hostnames in certificates. Ensure proxies forward SNI and host headers, that the correct certificate is attached to the virtual host or listener, and that firewall rules allow port 443 traffic to reach the component handling TLS.

Fixes and preventative measures are straightforward once you know the fault type. Renew or replace expired certificates promptly and ensure the issuing CA’s intermediate certificates are present on the server if required by the client chain. If mixed content is the cause, update page references to HTTPS or use protocol-relative URLs where appropriate, and test after changes using private browser sessions to avoid cached HSTS effects. Keep TLS libraries and server software patched, prefer modern TLS versions and secure cipher suites for compatibility and security, and consider automating renewals and monitoring certificate expiry to prevent recurrence.

Document the resolution steps, validate from multiple client environments, and add tests to your monitoring so similar outages are detected earlier in future. For reusable troubleshooting patterns and real-world infrastructure notes see this collection of Infrastructure posts on the blog at Build & Automate infrastructure. For more builds and experiments, visit my main RC projects page.