HSTS and the certificate expiry you can't click past

The button you're used to isn't there

Every engineer has clicked through a certificate warning. Self-signed cert on a staging box, expired cert on some internal tool nobody renewed, a hostname mismatch on a load balancer someone stood up in a hurry. You see the interstitial, you read "Your connection is not private," you find the "Advanced" link, you click "Proceed to site (unsafe)," and you get on with your day. That click-through is a safety valve. It's the difference between a certificate problem that's an annoyance and one that's an outage.

HSTS takes the valve away. On a host that has sent a valid HTTP Strict Transport Security header, or one that's on the preload list, there is no "proceed anyway." The browser refuses the connection, and there's nothing the user can do about it. Chrome shows a page with no override, no Advanced link, nothing to click. That's the entire point. HSTS exists to make TLS non-optional so an attacker can't strip it, and it does that job well. But it also means an expired certificate on an HSTS host stops being a warning and becomes a wall.

With TLS lifetimes on their way down to 47 days under CA/Browser Forum ballot SC-081v3, more of us are going to be renewing more certificates more often, and the hosts where a missed renewal hurts most are exactly the ones protected by HSTS. Worth understanding precisely what you're signing up for.

What HSTS actually enforces

HSTS is a response header. A server sends Strict-Transport-Security with a max-age value, and the browser records: for this host, for this many seconds, only ever connect over HTTPS, and treat any certificate error as fatal. No click-through. The header has three parts that matter, and each one widens your blast radius in a different direction.

max-age is how long the browser remembers the policy, in seconds. It's a sliding window. Every time you serve the header, the clock resets. A common production value is 31536000 — one year. So once a browser has seen your header, it enforces HTTPS-only on your host for a full year after the last visit, whether or not your server is still sending anything. You can't take it back by deleting the header. The browser is holding the policy, not you.

includeSubDomains extends the policy from the exact host to everything under it. Set it on example.com and every subdomain (api.example.com, admin.example.com, that legacy-reporting.example.com box you forgot existed) inherits HTTPS-only enforcement, no click-through, for the same max-age. This is where people get hurt, and I'll come back to it.

preload is a flag that opts you into something much bigger than a header.

Per-response HSTS versus the preload list

There are two entirely different mechanisms here, and conflating them is how teams walk into trouble.

The header-based version is per-response and trust-on-first-use. A browser only knows your policy after it has connected to you at least once over HTTPS and seen the header. The very first connection, before any header has been received, is unprotected. That's the gap preload closes.

The preload list is different in kind. It's a list of domains hardcoded into the browser binary itself. Chrome maintains it; Firefox, Safari, and Edge consume it. If your domain is on that list, every browser that ships with it enforces HTTPS-only on your domain from the first request, before it has ever talked to your server. There's no trust-on-first-use gap because the trust is compiled in. The catch cuts both ways: because the policy lives in the binary, changing it means shipping a new binary. Getting onto the preload list is a form submission. Getting off is a wait measured in browser release cycles.

Why SC-081v3 makes this sharper

Here's the arithmetic that should worry you. SC-081v3 walks maximum certificate lifetimes down in stages: the 200-day phase is already in effect as of March 2026, 100 days lands March 2027, and 47 days (with 10-day domain-validation reuse) arrives March 2029. Every one of those steps multiplies your renewal count. A cert you touched once a year now gets touched eight times a year. Run a hundred endpoints and that's eight hundred renewal events annually where before you had a hundred.

Renewals fail. ACM can't validate a DNS record because someone changed the zone. A certbot cron job dies because the ACME challenge path got blocked by a WAF rule. An Azure Key Vault access policy gets tightened and the automation that pulls the new cert loses permission. None of these are exotic; they're Tuesday. The more renewals you run, the more of them you hit, purely by volume.

Now overlay HSTS. On a normal host, a missed renewal produces a certificate warning. Ugly, embarrassing, survivable. Someone clicks through, you get paged, you fix it; the click-through kept the lights on for the people who really needed in. On an HSTS host, that same missed renewal produces a hard failure with no recovery path on the client side. The users can't proceed. Your status page, if it's on the same protected domain, can't be reached either. This isn't a degraded state. It's down.

Shorter lifetimes shrink the margin at exactly the point where the failure mode is least forgiving. A 398-day cert gave you months of slack to notice a renewal problem before the old cert actually expired. A 47-day cert gives you a couple of weeks. Compress the timeline and remove the click-through at the same time, and the cost of a single missed renewal goes way up.

The preload trap

The preload list is where good intentions get locked in, so treat submission as close to irreversible.

Getting onto it is easy. You add preload to your header, meet the requirements (serve over HTTPS, redirect HTTP to HTTPS, set max-age to at least a year, include subdomains), and fill out the form at hstspreload.org. Within a release cycle or two, browsers start shipping your domain baked in.

Removal is not the reverse of that. You can request it, but it only takes effect as browsers ship new releases carrying the updated list, and then only as users update their browsers. That's months, realistically, and you don't control the tail. Somebody running an old Chrome build keeps enforcing your policy long after you asked to come off. So if you preload example.com with includeSubDomains and later discover that intranet.example.com or some vendor integration only speaks plain HTTP, you can't just flip it back. You've committed every subdomain under your apex to HTTPS-only, in browsers you don't control, for a duration you can't set.

That includeSubDomains flag is the specific landmine. It doesn't ask which subdomains actually serve HTTPS. It applies to all of them, including the ones you forgot about: the legacy reporting tool, the internal dashboard, the IoT device console someone stood up on a subdomain years ago and never put a cert on. The day your preload entry ships, every one of those goes unreachable in a compliant browser, and there's no click-through to limp along on while you scramble.

Rolling it out without shooting yourself

HSTS is worth deploying. The protection against protocol-downgrade and SSL-strip attacks is real, and you should want it. Just do it in stages, and leave the least-reversible decisions for last.

Start max-age small. A few minutes — say 300 seconds. Serve the header, confirm your site still works, confirm the header is present and parsed correctly. Because max-age is short, if something breaks you're a few minutes from recovery once you stop sending it.

Then ratchet up in steps: minutes to hours to a day to a week, verifying at each stage that everything under the policy genuinely serves valid HTTPS. Give yourself time at each level to catch a problem while the memory window is still short. Only once you've held a long max-age cleanly should you go to a year.

includeSubDomains is a separate, deliberate decision, not something to tack on early. Before you set it, inventory every subdomain under the apex and confirm each one serves HTTPS with a valid cert, or is genuinely dead. This is the step where the forgotten HTTP-only service bites, so do the enumeration for real. Check what's actually resolving, not what you think is running.

Preload submission is dead last, and only after includeSubDomains with a one-year max-age has run in production without incident. Once you submit, assume you can't take it back on any useful timeline. Migrate or decommission every HTTP-only service anywhere under the apex first, because after preload ships there is no interstitial to fall back on for any of them.

Monitoring HSTS hosts is a different job

Which changes how you have to run them. HSTS-protected hosts have zero slack. Everywhere else, an expired leaf certificate is a warning a human can click past while you fix it. Here it's an incident with no manual recovery on the client side, and that should change how you monitor them.

Set tighter alert thresholds on HSTS and preloaded hosts than on the rest of your estate. If you page at seven days out for a normal endpoint, page earlier for one where expiry means a hard outage — and page harder, because there's no clicking through to buy time. Under 47-day lifetimes, a fixed-day threshold that was generous at 398 days can be uncomfortably close to the wire, so set it against how long your renewal-and-verify loop actually takes, not a round number.

And check the chain that's actually being served, not a record in a database. A cloud console saying a certificate is valid until some date tells you what's issued, not what's presented on the wire. The load balancer might be serving an old cert. A renewal might have completed in ACM but never propagated to the CloudFront distribution or the ingress that terminates TLS. The only way to know what a browser will see is to connect to the endpoint and read the leaf, the chain, and the expiry straight off the live handshake. On an HSTS host, the gap between "renewed in the backend" and "serving on the edge" is the gap between fine and down.

This is exactly what endpoint probing is for. CertPulse watches the certificate that's actually served on the endpoint — expiry, chain, TLS version — instead of trusting an inventory record, so on the hosts where there's no proceed-anyway button, you hear about it with real lead time rather than hearing about it from your users. And on an HSTS host, lead time is the whole game.

Deploy HSTS. It's good security. Just go in knowing you've traded the safety valve for the guarantee, and monitor the hosts where you made that trade like there's no click-through to fall back on. Because there isn't.