HSTS HTTPS Reliability

HSTS and Certificate Management: What Infrastructure Teams Need to Know

March 6, 2026 · 6 min read

HSTS is a browser security control, but it raises the operational stakes for every certificate behind your domain.

HTTP Strict Transport Security, usually shortened to HSTS, tells browsers to use HTTPS for a domain automatically. Once a browser has seen the HSTS header, it will refuse to downgrade to plain HTTP for that domain until the policy expires.

That is exactly what you want from a security perspective. HSTS protects users from protocol downgrade attacks and removes accidental HTTP access. But it also means your HTTPS endpoint must stay healthy. If your certificate expires, the chain is incomplete, or the wrong certificate is served, users cannot click through safely as a workaround.

What the HSTS header does

A basic HSTS header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age sets how long the browser should remember the rule. includeSubDomains extends the policy to every subdomain. Some sites also submit to the browser preload list, which bakes the HTTPS-only rule directly into browsers before a user ever visits the site.

Those settings are useful, but they are also commitments. If you include all subdomains, every hostname under that domain needs a valid HTTPS configuration. Forgotten test hosts, old admin panels, and partially migrated services become user-visible failures.

Why HSTS depends on certificate hygiene

HSTS does not fix certificate problems. It makes them more visible. A browser enforcing HSTS still validates the certificate chain, hostname, expiry, and trust path. If any of those fail, the user is blocked because the browser is not allowed to fall back to HTTP.

That means HSTS should be paired with reliable certificate management: full inventory, automated renewal, complete chain delivery, and monitoring from the outside. If you cannot answer which certificates protect a domain and its subdomains, you are not ready for aggressive HSTS settings.

A safer rollout pattern

  1. Inventory every hostname under the domain, including legacy systems and staging endpoints.
  2. Verify that all HTTPS services serve complete certificate chains.
  3. Start with a short max-age, such as one day or one week.
  4. Increase the duration only after monitoring confirms stable certificate renewal and delivery.
  5. Add includeSubDomains only when subdomain coverage is complete.
  6. Consider preload only when rollback risk is low and ownership is clear.

Where CertLocker fits

CertLocker helps with the part HSTS does not solve: knowing what certificates exist, where they are deployed, when they renew, and whether the live endpoint is serving what it should. The practical combination is HSTS for browser enforcement and CertLocker for certificate lifecycle control.

If your team is moving toward shorter certificate lifetimes, HSTS makes automation even more important. A 47-day certificate lifetime with manual renewal is already risky. A 47-day certificate lifetime on an HSTS-protected hostname leaves almost no room for slow manual recovery.

Related reading