HTTP vs HTTPS: TLS Certificates and Troubleshooting

What HTTPS protects

When someone signs in to an internal application, delivering the request is only part of the job: the credentials also need protection in transit. HTTP carries web requests and responses; HTTPS protects that exchange with TLS and lets the client authenticate the server. This article compares them through certificate checks, application responses and HSTS behavior.

HTTP vs HTTPS in Practice

HTTPS protects transport. It does not fix application vulnerabilities, incorrect permissions or account theft. A valid certificate does not establish the quality or legitimacy of a business. The original article uses the familiar term SSL, while current deployments use TLS.

Tools for inspecting TLS

Diagnostics use Ubuntu 24.04 LTS, OpenSSL 3 and curl. Proxy configuration uses Nginx. Match TLS 1.2 and 1.3 support to real clients.

The comparison has no VM sizing requirement. For an actual service, measure TLS overhead and concurrent connections alongside application load.

Replace app.example.com with your domain. Its certificate needs matching SANs and a valid chain. Restrict the private key and install any internal CA in the client trust store.

Older clients and HSTS policy

Cipher and handshake behavior differs between TLS 1.2 and 1.3, so check the versions and algorithms supported by older clients. HSTS is a browser policy that requires HTTPS for a site after the browser receives that policy over a valid HTTPS connection. A redirect alone does not protect the first HTTP request; do not assume HSTS protection before the browser has received a valid policy.

TLS protection boundaries

SSL is common terminology, but SSLv2 and SSLv3 are unsuitable for new services. HTTPS does not repair vulnerable application logic or compromised clients. Restrict keys, use a fixed trusted redirect hostname and assess replay risks before 0-RTT for state-changing requests.

Verify the certificate and introduce HSTS

The next commands check the certificate actually presented by the service from the client side. Replace app.example.com with the real endpoint name. Keep certificate verification enabled in OpenSSL and curl; bypassing it hides a trust failure.

HOST='app.example.com'
openssl s_client -connect "$HOST:443" -servername "$HOST" -verify_hostname "$HOST" -verify_return_error </dev/null
curl --fail --show-error --head "https://$HOST/"

Command completion alone is not a pass. Check Verify return code: 0 (ok), the hostname and the expected application response together. For an internal CA, use the client's trust store or --cacert with a trusted CA file. The -k option removes the trust check and cannot establish acceptance.

The Nginx guide in this library provides complete TLS configuration. Add this directive inside its HTTPS server block. It is not a standalone configuration.

add_header Strict-Transport-Security "max-age=300" always;

sudo nginx -t
sudo systemctl reload nginx
curl --fail --head https://app.example.com

Expect the header on HTTPS with a short max-age. Extend duration after hostname and renewal tests. IncludeSubDomains/preload require complete inventory and recovery planning.

For complete proxy and TLS configuration, see the Nginx guide. Related guide

Monitor the certificate actually served

Probe names, chains and expiry through the real client path. A valid disk file does not prove the service loaded it. Alerts at 30, 14 and 7 days are examples. Include an API request to distinguish application failures from TLS failures.

Diagnose certificate and browser failures

For an expired certificate, inspect notAfter and the client's actual clock. A hostname mismatch points to SAN, SNI and DNS; an unknown issuer calls for checking intermediate certificates and the trust store. If curl succeeds but the browser fails, investigate mixed content, HSTS and that browser's CA trust. OpenSSL can continue after a verification warning unless configured to stop, so read the verification result explicitly.

Renewal and HSTS recovery

Renewal is complete when the reloaded service presents the new certificate to clients, not merely when a valid file exists on disk. Protect the key, certificate and configuration backups. To reverse HSTS, clients must receive max-age=0 over valid HTTPS; offline clients do not receive the change immediately, and preload removal has a separate process and delay.

Test trust without bypasses

Assign certificate ownership and renewal procedures. Do not use curl -k for acceptance. Supply internal CAs through a trust store or trusted CA file to exercise the actual trust path.

Best Practices

Conclusion