TLS in 10 Minutes

Plain HTTP provides no confidentiality and no trustworthy server identity. Someone on the path can read requests, steal session cookies, change downloaded JavaScript, or redirect an API call. “This page has no password form” is not a reason to keep HTTP. A modified script can wait until the user enters a password somewhere else.

# HTTP: readable and modifiable on the path
GET /account HTTP/1.1
Host: example.com
Cookie: session=secret-value

# HTTPS: HTTP travels inside a TLS-protected connection
https://example.com/account

Before HTTP begins, the client offers protocol versions, cryptographic choices, and the hostname it wants. The server chooses compatible settings, sends its certificate chain, and proves possession of the matching private key. The client validates the chain and hostname. Both sides derive temporary session keys, then encrypt application data.

client                         server
  |--- ClientHello ------------>|  versions, cipher suites, SNI
  |<-- ServerHello -------------|  chosen parameters
  |<-- Certificate chain -------|  site cert + intermediates
  |<-- CertificateVerify -------|  proof of private key
  |--- Finished --------------->|
  |<-- Finished ----------------|
  |=== encrypted HTTP =========>|

Modern TLS uses ephemeral key agreement so stealing the certificate key later should not decrypt old captured sessions. Do not manually choose exotic cipher lists from an old blog post. Use a maintained server or platform's modern TLS policy, disable obsolete protocol versions, and spend your attention on certificates, private-key access, and renewal.

A site certificate contains a public key, validity window, issuer, and Subject Alternative Names. The requested hostname must appear in those names. The server normally sends its leaf certificate plus intermediate certificates. The client links that chain to a trusted root already in its trust store. The root usually should not be sent by the server.

# Inspect names, issuer, and dates from the live service
openssl s_client -connect example.com:443 -servername example.com \
  -showcerts </dev/null

# Inspect one saved certificate
openssl x509 -in cert.pem -noout -subject -issuer -dates \
  -ext subjectAltName

One IP address often hosts many HTTPS sites. The server needs to choose a certificate before it can read the encrypted HTTP Host header. Server Name Indication solves that by putting the requested hostname in the ClientHello. If SNI is missing or the server mapping is wrong, you may receive the default site's certificate.

# Correct: connect to the IP but send SNI for the hostname
openssl s_client -connect 203.0.113.10:443 \
  -servername api.example.com </dev/null

# Test the same routing with curl while preserving hostname
curl -v --resolve api.example.com:443:203.0.113.10 \
  https://api.example.com/health

ACME lets a certificate authority verify that you control a domain and issue a short-lived certificate automatically. HTTP-01 places a token under a well-known HTTP path. DNS-01 publishes a TXT record and is required for wildcard certificates. TLS-ALPN-01 proves control through a special TLS response on port four-four-three.

# HTTP-01 must be publicly reachable at this exact path
http://example.com/.well-known/acme-challenge/TOKEN

# DNS-01 publishes a temporary TXT value
_acme-challenge.example.com.  TXT  "challenge-value"

# Check public DNS before blaming the ACME client
dig +short TXT _acme-challenge.example.com

A reverse proxy often owns the public certificate and forwards requests to the application. That centralizes renewal and modern TLS settings. The application must still know the original request was HTTPS, and it must trust forwarded headers only from known proxies. For traffic across an untrusted network, encrypt the proxy-to-app hop too.

# Minimal nginx shape
server {
  listen 443 ssl http2;
  server_name example.com;
  ssl_certificate     /etc/ssl/example/fullchain.pem;
  ssl_certificate_key /etc/ssl/example/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Ordinary HTTPS authenticates the server. Mutual TLS also asks the client for a certificate, which is useful for service-to-service links, devices, and tightly controlled partner APIs. It is strong transport identity, but it is operationally expensive. You must issue, rotate, revoke, and map client identities without locking out every caller at once.

# Call an mTLS endpoint
curl --cert client.crt --key client.key \
  --cacert service-ca.crt https://internal.example.com/health

# nginx client verification
ssl_client_certificate /etc/ssl/client-ca.pem;
ssl_verify_client on;
ssl_verify_depth 2;

Do not use one shared client certificate for a hundred services. Give each workload an identity so a compromise can be revoked narrowly and logs name the caller. Keep application authorization after certificate verification. A valid certificate can prove “inventory service,” but the application still decides whether that service may cancel an order.

Start with the exact hostname and port the failing client uses. Inspect the live service rather than a certificate file you meant to deploy. Check SNI, Subject Alternative Names, validity dates, the served intermediates, and the client clock. Then compare trust stores; a browser and a container can disagree because they carry different root certificates.

# Fast HTTP and certificate trace
curl -Iv https://api.example.com/

# Verify what the server actually presents
openssl s_client -connect api.example.com:443 \
  -servername api.example.com -verify_return_error </dev/null

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate

Automated issuance is not enough. Renewal must run, install the new files where the active process reads them, and reload that process. Monitor the certificate observed from outside, not merely a successful cron exit. Test renewal while months remain. The first failure should be an alert, not a customer screenshot.

# Show expiry from the public endpoint
echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

# Generic post-renewal checks
acme-client renew
nginx -t && systemctl reload nginx
curl -fsS https://example.com/health

These commands answer most first-response questions without disabling verification.

# inspect live TLS with correct SNI
openssl s_client -connect HOST:443 -servername HOST -showcerts
curl -Iv https://HOST/

# inspect certificate file
openssl x509 -in cert.pem -noout -subject -issuer -dates \
  -ext subjectAltName

# diagnose by symptom
wrong hostname → URL + SAN + SNI + virtual-host mapping
unknown issuer → served intermediates + client CA store
expired → public notAfter + renewal + reload
ACME failure → DNS + challenge path + reachable port

# rules worth keeping
serve leaf + intermediates · protect private key · automate renewal
monitor from outside · never use -k or verify=False in production

My blunt version: TLS libraries are usually not your problem. Deployment is. Serve the right certificate for the requested name, include the intermediate chain, automate renewal and reload, and test the endpoint from outside your network. When verification fails, fix the name, chain, date, or trust store. Turning verification off converts an actionable error into silent impersonation.