SSL/TLS and HTTPS operations

TLS provides confidentiality, integrity and server authentication for one connection. It does not authorise the client, protect data after it reaches the application, or hide which host the client asked for unless Encrypted Client Hello is deployed.

• Confidentiality: traffic cannot be read in transit
• Integrity: modification is detected through authenticated encryption
• Authentication: the server proves possession of the certificate key
• Not authorisation: access control remains the application's job
• Not metadata privacy: SNI and IP addresses are often still visible

The client offers capabilities, the server selects parameters and presents a certificate, both sides derive shared keys, and a Finished message authenticates the transcript. TLS 1.3 shortened this to one round trip by encrypting most of the handshake.

• ClientHello carries supported versions, cipher suites, SNI and a key share
• ServerHello selects parameters and contributes its own key share
• The server proves key ownership by signing the transcript
• Session resumption with pre-shared keys removes the full handshake on reconnects
• 0-RTT early data has replay caveats and suits idempotent requests only

Modern suites pair an ephemeral key exchange with an authenticated cipher. Forward secrecy means recorded traffic stays unreadable if a long-term key leaks later, because session keys were never derived from that long-term key.

• TLS 1.3 permits only ephemeral (EC)DHE key establishment
• Prefer AES-GCM or ChaCha20-Poly1305 over CBC-based suites and their padding history
• Retire TLS 1.0 and 1.1, and keep TLS 1.2 only with modern suites
• Session ticket keys are secrets too: rotate them like any other key

One IP address can serve many hostnames, so the server chooses a certificate using SNI. Getting the right certificate and the complete chain to the client is a configuration concern that differs between load balancers, CDNs and origin servers.

• Send the leaf first, then the intermediates, in that order
• Wildcards cover exactly one label: *.example.com does not cover a.b.example.com
• Mutual TLS authenticates clients with their own certificates and a trusted client CA
• TLS-terminating proxies hold the key, so their custody and configuration matter

Most certificate outages are process failures, not attacks: renewal did not run, the reload did not happen, or the chain was incomplete in one environment. Automation plus monitoring removes both failure modes.

• Renew with ACME or an equivalent automation, and reload the service after renewal
• Monitor expiry, chain validity and hostname match from outside the network
• Publish HSTS only after every path and subdomain serves HTTPS
• Plan for shorter maximum lifetimes, where manual renewal stops being viable
• Keep one known-good certificate and key available for rollback

Diagnose from the client's point of view, using the exact hostname the application uses. Most errors reduce to four causes: an expired certificate, a name mismatch, an incomplete chain, or an untrusted issuer.

• openssl s_client -connect host:443 -servername host -showcerts prints the presented chain
• Never fix a certificate error by disabling verification
• Behind a TLS-inspecting proxy, trust is delegated to the proxy's private CA by design