HTTPS Configuration Best Practices Every Developer Should Ship

Getting a padlock in the address bar is the easy part. Getting HTTPS configured so it actually resists downgrade attacks, mixed content leaks, and certificate expiry outages is where most teams quietly fail. Below is what a production-grade HTTPS setup looks like in 2025, with the specific settings, headers, and gotchas worth knowing.

Start with the right TLS versions and ciphers

Most servers still ship with defaults that allow weak protocols or legacy ciphers for "compatibility". In practice, you only need TLS 1.2 and TLS 1.3. Everything older is a liability.

What to enable

• TLS 1.3 — preferred, faster handshakes, forward secrecy by default.
• TLS 1.2 — keep for older clients, but restrict cipher suites.
• Disable TLS 1.0, TLS 1.1, SSLv3, and SSLv2 entirely.

Nginx example

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_ecdh_curve X25519:secp384r1;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

The Mozilla SSL Configuration Generator is a reliable starting point — pick the "intermediate" profile unless you have a specific reason to support ancient clients.

Force HTTPS everywhere, then commit with HSTS

A redirect from http:// to https:// is not enough on its own. The first request still goes out in plaintext and can be intercepted. HSTS (HTTP Strict Transport Security) tells the browser to never speak HTTP to your domain again.

The header to ship

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age=63072000 — two years, the value required for preload submission.
• includeSubDomains — protects every subdomain. Only add this once you've confirmed all subdomains serve HTTPS.
• preload — opt in at hstspreload.org to be baked into Chrome, Firefox, and Safari.

Be careful: preload is effectively permanent. If you submit example.com with includeSubDomains and later need to expose a plain HTTP service on a subdomain, you're stuck. Start with a shorter max-age, verify nothing breaks, then ramp up.

Automate certificates — manual renewals will burn you

Expired certificates are still one of the most common causes of outages. Don't rely on calendar reminders.

1. Use Let's Encrypt or your cloud provider's managed certs (ACM, Cloudflare, GCP).
2. Run certbot or acme.sh on a cron schedule, renewing at 30 days before expiry.
3. Monitor expiry externally — don't trust the server that issues the cert to also tell you when it's broken.
4. Use short-lived certificates (90 days is the de facto standard) so renewal automation is exercised constantly.

For multi-domain setups, prefer SAN certificates over wildcards where possible — they're easier to revoke and rotate without affecting unrelated services.

Lock down OCSP and certificate transparency

Enable OCSP stapling so the server delivers the revocation status alongside the certificate. This avoids a separate client round-trip to the CA and removes a privacy leak.

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Also consider CAA DNS records to declare which CAs are allowed to issue for your domain:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"

Fix mixed content before it ships

A single <img src="http://..."> can break the padlock, trigger console warnings, and on some browsers, block the request entirely. Audit for:

• Hardcoded http:// URLs in templates, CSS, and JavaScript bundles.
• Third-party scripts loaded over HTTP (analytics, fonts, embeds).
• User-generated content with absolute HTTP links.
• Old database rows storing absolute URLs from a previous environment.

Add a Content Security Policy directive to surface anything you've missed:

Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-content

Running a scan with WebSentry will flag mixed content and weak TLS configurations in one pass, which is useful when inheriting a site you didn't build.

Set the security headers that complement HTTPS

HTTPS alone doesn't stop a compromised script from exfiltrating data. Layer on:

• Content-Security-Policy — restrict script, style, and connect sources.
• X-Content-Type-Options: nosniff — prevent MIME sniffing.
• Referrer-Policy: strict-origin-when-cross-origin — limit referrer leaks across HTTPS boundaries.
• Permissions-Policy — disable APIs you don't use (camera, geolocation, payment).
• Cross-Origin-Opener-Policy: same-origin — isolate browsing contexts.

Cookies: HTTPS-only or don't bother

Every cookie should be set with three flags at minimum:

• Secure — never sent over HTTP.
• HttpOnly — invisible to JavaScript, mitigates XSS-based theft.
• SameSite=Lax or Strict — limits CSRF exposure.

Session cookies without Secure are still common, especially in frameworks where the default depends on environment detection. Always set it explicitly in production config rather than trusting auto-detection.

Test from outside your network

Internal smoke tests miss things like SNI misconfiguration, intermediate certificate chain issues, and stale CDN edge certs. Validate from external tools:

• openssl s_client -connect example.com:443 -servername example.com for raw handshake inspection.
• SSL Labs for a deep grade and chain analysis.
• WebSentry for an A–F grade that covers TLS, headers, cookies, CORS, and DNS in one report — handy for client-facing audits where you need a single artifact.

Common misconfigurations worth checking right now

• Wildcard certificates served on the apex domain but not on www, or vice versa.
• HTTP/2 enabled but with cipher suites HTTP/2 explicitly bans, causing fallback to HTTP/1.1.
• HSTS set on the apex but missing on subdomains that authenticate users.
• Redirects that chain http://example.com → http://www.example.com → https://www.example.com, exposing two plaintext hops.
• Old TLS 1.0/1.1 enabled on a staging subdomain that shares cookies with production.

Fix the chained redirect issue by going directly from any HTTP variant to the canonical HTTPS host in a single 301.

Once your TLS, HSTS, cookies, and headers are dialled in, run a free scan at websentry.dev to confirm nothing slipped through — and to get a shareable grade you can hand to clients or stakeholders.