Recover a Domain Locked by HSTS After You Lose Clear
Direct Answer: An HSTS policy pins a domain to HTTPS after a max‑age period, preventing HTTP redirects or certificate changes. When the lock persists after expiration, you must clear the stored state via browser devtools, update TLS certificates, and reset the HSTS preload list, then verify with a tool like SarangAI's HSTS checker.
When HSTS blocks access after a misconfigured max-age, learn how to purge the lock and regain control of your domain safely.
At 02:34 UTC on March 12, 2024 a pager went off. The client’s checkout page returned 500 errors and the browser console printed:
Refused to display 'https://shop.example.com/' as a non‑HTTPS page, because it is listed in the browser's [HSTS](/tools/headers) preload list.
The error was not a certificate expiry; it was the browser refusing to fall back to HTTP even after the SSL chain had been replaced. The incident forced a midnight scramble to understand why the HSTS lock remained.
How HSTS Locks a Domain
The Strict‑Transport‑Security (STS) header looks like this when a server enables the feature:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
When a browser first sees the header, it stores three pieces of data locally:
- The max‑age value (seconds the policy must be honored). 31536000 = 1 year.
- The includeSubDomains flag (applies to all subdomains).
- The preload flag (adds the host to Chrome’s built‑in preload list).
After the max‑age expires, the browser still honors the policy until the host is removed from the preload list or the user clears the state. The preload list is a static file shipped with Chrome; removing a host requires editing that file, which most developers never do.
A typical request flow:
- Client attempts
https://shop.example.com/. - Server returns the TLS certificate and the STS header.
- Browser validates the certificate against its trust store.
- If validation passes, the browser records the STS state.
- Subsequent requests are automatically upgraded to HTTPS, even if the original request was HTTP.
If the certificate changes while the old max‑age is still active, the browser will reject the new cert, displaying NET::ERR_CERT_AUTHORITY_INVALID or CERTIFICATE_TRANSPARENCY_REQUIRED. The lock is now in effect.
Failure Case Study: A 2 a.m. Pager Alert
Symptom (timestamp): 02:34 UTC, March 12, 2024
Error line in console: Refused to display 'https://shop.example.com/' as a non‑HTTPS page, because it is listed in the browser's HSTS preload list.
Root cause: The production certificate for example.com expired on February 28. The DevOps team replaced it with a new Let's Encrypt certificate but left the old STS header unchanged. Because the domain is in Chrome’s preload list, browsers continued to enforce HTTPS with the expired chain, causing 500 errors on the checkout endpoint.
Resolution timeline:
About the author
Admin SarangAI · AI Tools Editor
Part of the SarangAI editorial team covering AI tools, product releases, emerging technology trends, and practical web utilities for developers and creators.