HTTPS & TLS

The client sends ClientHello with supported ciphers, the hostname in SNI, ALPN protocols and a key share for an ephemeral Diffie-Hellman exchange. The server answers with ServerHello and its own key share, and both derive the same session keys. From then on everything is encrypted: the server sends its certificate chain, a signature proving it holds the private key, and Finished. The client validates the chain and hostname, sends Finished and can immediately send the HTTP request. That is one round trip, compared with two in TLS 1.2. Ephemeral keys give forward secrecy, so a later key leak cannot decrypt recorded traffic.

Browsers and operating systems trust a small set of root CA certificates. Roots sign intermediate CAs, and intermediates sign site certificates. When a server presents its leaf certificate plus the intermediates, the client verifies each signature up the chain until it reaches a trusted root, and checks validity dates, the hostname in Subject Alternative Name, and key usage. If an intermediate is missing, some clients can fetch it and others fail, which is why curl or mobile apps may break while desktop browsers work. Roots stay offline and protected; intermediates can be rotated without changing what devices trust.

Automation plus monitoring. I use certbot or another ACME client with the systemd timer or cron, a deploy hook that reloads nginx, and I run certbot renew --dry-run after setup and after any server change. Port 80 stays open for HTTP-01, or I use DNS-01 with a scoped API token. Then I monitor from outside: an uptime tool that alerts when a certificate has less than about two weeks left. Lifetimes are getting shorter across the industry, heading to 47 days by 2029, so anything manual will fail eventually. Behind a CDN the edge certificate is managed, but the origin still needs the same care.

HSTS is a response header, Strict-Transport-Security, that tells the browser to use only HTTPS for this domain for a period such as a year. After the first visit, the browser upgrades http:// links itself and refuses to let users click through certificate errors, which blocks SSL-stripping attacks. With the preload list, browsers enforce it even on the very first visit. The risk is lock-in: if any subdomain covered by includeSubDomains does not support HTTPS, or a certificate breaks, users cannot reach it. So I start with a short max-age, verify all subdomains, then increase it, and preload only when certain.

The server is most likely sending only its leaf certificate without the intermediate. Desktop browsers often hide this because they cache intermediates or download them using the AIA extension, but curl, many mobile clients, Node and Java do not. The fix is to configure the full chain: in nginx, ssl_certificate should point to fullchain.pem from certbot, not cert.pem. I verify with openssl s_client -showcerts and check that the intermediate appears, or use an online SSL checker. Less often, the client machine itself has an outdated CA bundle that needs an update.

Each hop should be encrypted when it crosses a network you do not fully control. The CDN terminates the visitor's TLS. From CDN to origin I use Full (strict) with a valid certificate, ideally plus authenticated origin pulls. A load balancer may terminate and re-encrypt, or pass TLS through to nginx; termination there simplifies certificate management, re-encryption keeps data protected inside the network. Between nginx and containers on the same host over a private Docker network, plain HTTP is a common, acceptable trade-off. Across hosts or in shared clusters, use TLS or mTLS, often via a service mesh. Fewer termination points mean fewer keys to protect, but every hop that inspects traffic needs its own certificate and rotation.

Assume nothing manual survives. Inventory every certificate: web servers, load balancers, mail, VPN, appliances and anything using a certificate file copied by hand. Move each one to ACME automation, or to a managed service such as a CDN or cloud load balancer that renews itself. Use ARI-capable clients so the CA can signal early renewal. Make reloads automatic through deploy hooks, and make sure configuration management does not overwrite renewed files. Monitor externally for expiry and for chain errors, alerting well before a third of the lifetime remains. Devices that cannot run ACME should sit behind a proxy that can. The investment pays off beyond compliance: rotations become routine, so an emergency revocation is no longer stressful.

Pinning makes the app accept only specific keys, which blocks interception even if a user installs a rogue CA or a CA is compromised. The cost is fragility: if you rotate keys without the app knowing, every installed version stops working, and with short certificate lifetimes rotation is frequent. If pinning is required, pin the public key of an intermediate or your own long-lived key rather than the leaf, always ship backup pins, provide a remote way to update or disable pinning, and keep the same key across renewals where your CA process allows it. For most apps, standard TLS validation plus Certificate Transparency checks on the platform is enough. Banking and high-risk apps are where pinning usually pays off.