Direct Answer: A domain locked by HSTS blocks all HTTP traffic until the stored max‑age expires or the certificate is replaced. Clear the entry via browser devtools, force a new certificate, or adjust DNS TTL. The SarangAI SSL checker validates the chain and reveals stale HSTS records.
Quick guide to clearing a stale HSTS entry, checking certificates, and preventing future lockouts.
What is HSTS and how does it cause a lock?
HTTP Strict Transport Security (HSTS) is a web security policy delivered via the Strict-Transport-Security header. When a browser first receives this header it records three pieces of data: the host, a max‑age value (seconds the policy must be honored), and optionally includeSubDomains or preload. The browser then enforces HTTPS for that host for the duration of max‑age. If the server later presents an invalid or expired TLS certificate, the browser will not fall back to HTTP; it will simply keep the lock because the stored policy cannot be overwritten until max‑age passes. The lock becomes visible when a user or an automated client (e.g., a CI script) attempts an HTTP request and receives a 301/302 redirect that the browser ignores, or when tools like curl -v show Invalid certificate and the client cannot proceed.
How HSTS actually works at the protocol level
Client first visit – The server sends Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.
Browser stores – Chrome, Firefox, Edge, and others write the host and expiration timestamp into a local store (HSTS table in Chrome’s Network storage).
Subsequent requests – All HTTP URLs are automatically upgraded to HTTPS by the browser. If the HTTPS handshake fails (certificate mismatch, revocation, or expiration), the browser will not retry HTTP; it shows an error page.
Expiration – After max-age seconds the entry is removed, and the lock is cleared automatically.
Preload list – If the domain is in the public preload list (e.g., https://hstspreload.org), browsers ship the entry with the OS, meaning the lock exists even without a prior visit.
The lock is therefore a combination of a local cache entry and, optionally, a global preload list. Recovering a locked domain requires either removing the local entry, updating the certificate chain, or both.
Comparison of common HSTS configuration options
Option
Typical max-age (seconds)
includeSubDomains
preload
Impact on lock recovery
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.
A 3‑hour production outage: When HSTS kept users on HTTP
At 02:12 UTC on March 12 2024, a client’s production site client.example.com reported a spike in support tickets. Users trying to access the site via http://client.example.com were redirected to HTTPS but saw “Your connection is not private”. The internal monitoring dashboard showed a sudden rise in SSLHandshakeError for port 443, with the exact line:
java.net.SSLHandshakeException: java.security.cert.CertPathValidatorException: Invalid CA certificate
The root cause was a mis‑issued intermediate certificate from the previous CA. The new certificate had been deployed, but the HSTS max-age of 31 days was still active in browsers and in the public preload list. Because the old certificate chain was invalid, browsers enforced the stored HSTS policy and refused any HTTP fallback.
The fix required three actions:
Remove client.example.com from the public preload list (request removal via the HSTS preload submission form).
Force a certificate chain replacement with a new intermediate that anchored to a trusted root.
Instruct users to clear the HSTS entry locally (see the remediation steps below).
The entire recovery took 2.5 hours. After the preload removal, the SarangAI SSL chain checker confirmed a clean chain, and traffic returned to normal.
Failure Case Study
This incident shows a real production outage where an outdated HSTS preload entry combined with a broken certificate chain caused a 2.5‑hour service disruption. The exact error java.net.SSLHandshakeException: java.security.cert.CertPathValidatorException: Invalid CA certificate appeared in the logs at 02:12 UTC on March 12 2024. The fix involved removing the host from the public preload list, replacing the intermediate certificate, and guiding users to clear the local HSTS store. Recovery took 2.5 hours, validated by the SarangAI SSL chain checker.
Step‑by‑Step: Recovering a Domain Locked by HSTS
Remediation Walkthrough
The following eight steps detail the exact commands, configuration changes, and expected outcomes to clear a domain locked by HSTS. Each step is designed to be run in order, with verification after every action.
Expected: The header is present. If you see a curl error such as curl: (60) SSL certificate problem: unable to get local issuer certificate, the certificate chain must be fixed before proceeding.
Inspect the HSTS entry in the browser Chrome: chrome://settings/cookies → site client.example.com. Delete the “Strict Transport Security” entry. Firefox: about:config → temporarily set network.cookie.cookieBehavior to 0, then clear the HSTS store via browser.component.enable. Expected: The host no longer appears in the HSTS store.
Force DNS TTL refresh (if the lock is propagated via DNS‑based HSTS)
Expected: The DNS record is removed; the next DNS propagation clears the stored policy.
Run the SarangAI SSL chain checker
Open the free tool, paste client.example.com, and note any “chain broken” warnings. Expected: No errors; the checker confirms a valid chain and that the site is not in the preload list.
Deploy the updated certificate
Update the web server config (/etc/nginx/sites-available/client.example.com) and reload. Expected: nginx -t passes and systemctl reload nginx succeeds.
Expected: The edge cache (e.g., Cloudflare) purges the HSTS header, ensuring new clients receive the fresh policy.
Test from a fresh machine
Use a VM with a clean OS install, run curl -v http://client.example.com, then curl -v https://client.example.com. Expected: HTTP redirects to HTTPS and the HTTPS handshake succeeds.
Common Mistakes When Trying to Clear a Stale HSTS Entry
Mistake
Wrong Behavior
Correct Action
Ignoring the preload list
Assuming a local delete will clear the lock
Request removal from the public HSTS preload list via the submission form
Updating only the certificate
The browser still holds the old max-age and rejects connections
Reduce max-age on the new header or issue a short‑lived certificate to speed expiration
Using a generic DNS flush
HSTS is not a DNS record, so nslookup does nothing
Directly edit the server’s Strict-Transport-Security header values
Assuming max-age=0 works
Some browsers ignore max-age=0 if the entry is preloaded
Delete the preload entry or use includeSubDomains removal
Not checking the chain before clearing HSTS
You may clear HSTS but still have a broken SSL configuration
Run openssl verify first to confirm a valid trust chain
Running the script (python3 inspect_hsts.py client.example.com) prints the header or informs you that it is missing, which is useful for CI pipelines that need to enforce HSTS compliance.
Preventive measures: configuring HSTS safely
Start with a short max-age (e.g., 2592000 seconds = 30 days) while testing.
Use the free SSL chain checker to validate that the certificate chain is anchored to a trusted root before enabling HSTS.
Add the site to the preload list only after confirming that all subdomains work over HTTPS for at least 24 hours.
Monitor the free DNS propagation checker on SarangAI after any HSTS change to ensure the new header reaches the edge.
Keep the intermediate certificate updated well before expiration to avoid a broken chain that would lock the domain.
Key Takeaways
HSTS locks a domain by storing a max‑age entry; the lock cannot be overwritten until expiration or the entry is removed.
A broken certificate chain combined with an active HSTS policy causes immediate HTTPS failures and blocks HTTP fallback.
Recovery steps: verify the chain, delete the HSTS entry locally, remove the preload listing, refresh DNS TTL, and redeploy a valid certificate.
Common pitfalls include ignoring preload lists, assuming max-age=0 works, and not validating the SSL chain before clearing HSTS.
Use the SarangAI SSL chain checker, openssl s_client, and the free DNS propagation checker regularly to catch stale entries early.
Frequently Asked Questions
What is HSTS and why does it lock a domain?
HSTS forces HTTPS after the first visit, storing a max‑age value that browsers will not overwrite until it expires, effectively blocking HTTP requests.
How can I see the HSTS header on a live site?
Use curl -I https://example.com or open DevTools → Network → Headers to view the Strict‑Transport‑Security response.
What does a “cert chain broken” error mean in the context of HSTS?
It indicates the server cannot present a valid trust chain to a root CA, causing browsers to enforce the stored HSTS policy and reject insecure connections.
Can I clear a stuck HSTS entry without waiting for expiration?
Yes. Remove the host from the browser’s certificates store or delete the HSTS entry via about:config (Firefox) or by clearing the cache on Chrome.
How does the SarangAI SSL checker help with HSTS recovery?
It scans the certificate chain, flags mismatched issuers, and shows whether the site is still listed in public HSTS preload lists, guiding you to the correct fix.
