A Minimal TLS and HSTS Checklist for a Self-Managed VPS

Managing SSL yourself on a VPS (instead of an automatic platform like Vercel or Netlify) means you’re fully responsible for the TLS configuration. There’s no magic button that sorts everything out automatically once a domain is attached. Here’s what’s set up in Nginx for gookkis.com, and why each piece is there.

Certbot for certificates, then forget about it

Let’s Encrypt via Certbot, with auto-renewal through certbot’s built-in cron/systemd timer. Once it’s set up, there’s nothing to think about again as long as the server keeps running — no “certificate expiring soon” panic at midnight. One thing I learned the hard way: actually test the renewal (certbot renew --dry-run), don’t just assume the cron job is running. I once found an old server where certbot was “installed” but the systemd timer had silently died after an OS upgrade, and it only surfaced once the certificate had actually expired.

Restrict TLS protocols

I set ssl_protocols TLSv1.2 TLSv1.3; — disabling older TLS versions (1.0/1.1) that are already considered insecure and unsupported by modern browsers anyway. There’s no reason to keep supporting old protocols on a new site; the only clients that still need them are usually ancient browsers that send essentially zero traffic to a personal site like this.

HSTS header

Strict-Transport-Security with max-age=31536000; includeSubDomains forces browsers to always connect over HTTPS to this domain (and its subdomains) for the next year, even if a user types http:// manually. This closes the downgrade-attack window on the first request — the classic weak point where an attacker can intercept the initial HTTP request before it gets redirected to HTTPS.

Extra security headers

X-Frame-Options: SAMEORIGIN to prevent clickjacking, X-Content-Type-Options: nosniff to stop browsers from guessing a file’s MIME type in ways that can be abused. Small, but free to add and there’s no downside.

Forced redirect

Every request to port 80 (http://) gets a 301 redirect to https:// in a separate server block, before it can hit any SSL logic at all. This is what makes the HSTS header above actually effective — without this redirect, the first request coming in over http:// never gets a chance to “teach” the browser about HSTS in the first place.

Once all of this was in place, I ran it through SSL Labs — got an A, not an A+ (an A+ needs a more involved setup like custom OCSP stapling and hand-tuned cipher suites, plus HSTS preload list submission). I deliberately didn’t chase an A+ for a personal static site like this; the extra effort isn’t worth it against the risk I’m actually facing. The priority is not missing any of the basics, not squeezing out enterprise-level optimization. This simple checklist covers that, and I’d rather spend the extra time on something that actually gets used.