HTTPS and access
Choose TLS and HSTS policy
Use current protocol settings, secure session behavior, and HSTS only after HTTPS is complete across the domain.
8 minute lesson
TLS policy changes over time, so start from current Nginx and certificate-provider guidance rather than old copied snippets. A config pasted from a 2015 blog post ships protocol versions that scanners now flag and browsers now warn about.
Today the defensible baseline is short:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_protocols disables the obsolete versions — TLS 1.0 and 1.1 have no legitimate audience left. With only modern protocols enabled, ssl_prefer_server_ciphers off lets clients pick the cipher best suited to their hardware. The shared session cache lets returning clients resume sessions instead of paying for a full handshake, which is a measurable latency win.
Alongside the protocol settings, keep certificate renewal automated and monitor expiry. An expired certificate takes the site down more reliably than any cipher choice ever will.
HSTS is a commitment, not a checkbox
HSTS (HTTP Strict Transport Security) tells browsers to require HTTPS for your domain for a period:
add_header Strict-Transport-Security "max-age=31536000" always;
Once a browser sees this header, it refuses plain HTTP for max-age seconds — a year, here — and there’s no server-side undo. That’s the point, and that’s the risk. So roll it out in stages: start with a small max-age like 300, confirm nothing on the domain still needs HTTP, then raise it.
The includeSubDomains token extends the promise to every subdomain. Add it only when every subdomain is ready. The classic disaster is enabling it on example.com while intranet.example.com still runs plain HTTP: every browser that visited the main site now refuses to open the intranet, for the full max-age, and you can’t fix it remotely.
Verify what you’re serving:
curl -sI https://www.example.com/ | grep -i strict
# strict-transport-security: max-age=31536000
Then test the whole TLS configuration with a current external scanner such as SSL Labs. It checks protocol versions, chain, and HSTS from the outside and tells you what real clients experience. Repeat the scan after any TLS change.
Document your supported TLS versions and your HSTS decision, including the max-age schedule. Preserve a rollback path for compatibility changes — protocols you can re-enable in one line, and an HSTS max-age you grew gradually instead of jumping straight to a year.
Lesson completed