Quick answer: An HSTS error is a certificate failure with the escape hatch removed. The site once told your browser to load it only over HTTPS, so when the certificate expires or stops matching the hostname, the browser blocks the page and hides the "Proceed anyway" link. Visitors clear the stored policy in their own browser. Owners fix the certificate at the server.
Last verified: September 2026, checked against Chrome 153 stable (Chrome moved to a two-week release cycle with that milestone on 8 September 2026), Firefox's current binary HSTS store, and the hstspreload.org removal policy.
Our engineers work through 20 to 30 client issues a day, and this block arrives in two very different shapes: one person locked out of one site on one laptop, or an owner watching every visitor get locked out at once. Both fixes are below in full, with the commands we run ourselves.
Why Your Browser Refuses to Let You Through
The browser is doing exactly what the site asked it to do. Strict-Transport-Security is a response header that says, in effect, never speak plain HTTP to this hostname again, and never let the user click past a certificate warning. Every major browser honours it.
As of September 2026, a stored policy commonly lasts 31536000 seconds, a full year, counted from the last time the site sent the header over a working connection. Through that entire year the browser refuses any insecure fallback for that hostname, which is why a certificate that lapsed an hour ago can lock out every returning visitor while a first-time visitor on a fresh profile still gets through.
That asymmetry confuses people, and the on-screen wording makes it worse. An HSTS error almost never means the policy itself is broken. Chrome pairs a NET::ERR_CERT code with a separate line about HSTS, which reads like two faults. It is one fault plus one consequence: the certificate failed, and the policy removed your usual way around it. Both the MDN reference for the Strict-Transport-Security header and RFC 6797, the HSTS specification describe the header as a promise the site makes. The block is your browser keeping that promise.
Can I just type thisisunsafe and get in?
No. The Chromium bypass phrase works on an ordinary certificate interstitial, and a host with an active policy does not show one, so there is nothing to unlock. If typing it does let you in, the warning was a plain certificate warning and HSTS was never the thing stopping you. Clear the stored policy first, and the normal bypass becomes available again.
What Causes an HSTS Error, Ranked by Frequency
- An expired SSL certificate. Far ahead of everything else. Let's Encrypt certificates live 90 days, and renewal fails quietly, sometimes for weeks before anyone notices. Certbot Renewal Failed? Fix Let's Encrypt SSL (2026) covers the usual causes.
- A certificate that misses the hostname. The certificate covers example.com, the policy reaches every subdomain through includeSubDomains, and shop.example.com has nothing valid of its own.
- An origin and proxy mismatch. Cloudflare set to Full while the origin serves a self-signed or lapsed certificate. That normally appears first as Cloudflare Error 525 or Error 526.
- A half-finished migration. DNS already points at the new server, the new server has not issued a certificate yet, and the old policy is still sitting in everyone's browser.
- Local and staging hostnames. localhost, .local and .test names with self-signed certificates, plus internal admin panels.
According to Hostaccent's support-queue pattern through 2026, the 20 to 30 client issues our team clears each day include a steady trickle of these blocks, and in nearly all of them the certificate had lapsed or stopped matching. The header itself is almost never at fault. That ranking is worth trusting, because it tells you where to look first: check expiry before you change any configuration.
If a certificate changed without your knowledge, treat it as a security question before a configuration one. Google's "this site may be hacked" warning often turns up in the same week.
Fix It as a Visitor: Delete the Stored Policy
Clearing a stored policy takes about two minutes and changes nothing for anybody else. It affects the one browser on the one device you clear it on, so it is the right move for staging sites, admin panels and local development, and the wrong move for a live site your customers are trying to reach.
Chrome, Edge, Brave and other Chromium browsers
- Open
chrome://net-internals/#hsts(edge://net-internals/#hstson Edge). - Under Query HSTS/PKP domain, enter the hostname and click Query to confirm an entry exists.
- Under Delete domain security policies, enter the same hostname and click Delete.
- Close every tab for that site, then restart the browser.
Preloaded entries cannot be deleted here. If Query returns a result that will not clear, the domain ships inside the browser binary itself and only the owner can begin removal.
Firefox
Firefox has no per-site delete box. Open History with Ctrl+H (Cmd+Shift+H on macOS), right-click the site, and choose Forget About This Site. Plenty of guides still tell you to edit SiteSecurityServiceState.txt in your profile folder. Current Firefox keeps that state in a binary file instead, so hand-editing is no longer an option, and any guide still recommending it is likely stale in other ways too.
Safari
Quit Safari completely, then clear the site's data under Settings, Privacy, Manage Website Data. On macOS the policy lives in ~/Library/Cookies/HSTS.plist, which you can move aside while Safari is closed if the interface route does not take.
Pro Tip: Test in a fresh private window after clearing. A normal window often replays the old redirect from cache and makes a working fix look like a failed one.
Still working through this server issue?
Send the symptoms, error output, and what you have already tried. We can work with Hostaccent services or infrastructure hosted with another provider.
Fix It as a Site Owner: Repair the Certificate First
Owners fix this at the origin, never in a browser. Reissue or renew the certificate so it is valid, trusted, and covers every hostname the policy reaches, subdomains included when includeSubDomains is set. Let's Encrypt certificates last 90 days, so automated renewal plus expiry monitoring is the actual fix. Visitors recover the moment a good certificate is served.
Run these in order:
- See what the server is really presenting:
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates -subject. - Test the renewal path, not just today's certificate:
certbot renew --dry-run. The Let's Encrypt documentation covers the client and its rate limits. - Reload the web server so the new chain is in memory:
systemctl reload nginxorsystemctl reload apache2. - Confirm every hostname the policy covers, www and subdomains included, has its own valid certificate.
Insider Insight: includeSubDomains is the directive that turns one expired certificate into a site-wide outage. Across the 4,000+ sites Hostaccent has migrated since 2016, the step most often missed is checking that mail, staging and shop subdomains carry certificates of their own before that directive goes live.
Live site, and no time to experiment? Our engineers repair the certificate and the policy behind this block for a small one-time fee, and you see the exact quote before anyone touches your server. Hosted with Hostaccent? Then this is simply covered by support, at no charge. Have an engineer fix it
When the domain sits on the preload list
To remove the domain from the HSTS preload list, serve a valid header without the preload directive, keep HTTPS working, then submit it through the official HSTS preload removal form. Removal takes roughly 6 to 12 weeks to reach most Chrome users and longer on other browsers, because the list travels inside the browser binary. Sending Strict-Transport-Security: max-age=0 switches off your own policy, but it does nothing to a preloaded entry.
Confirm the Fix and Keep It From Coming Back
Two commands settle it. openssl s_client -connect example.com:443 -servername example.com prints the certificate dates and chain, and curl -sI https://example.com | grep -i strict-transport-security shows whether the header comes back and what max-age it carries. Current dates plus a clean header means every browser recovers on its next request, with nothing for visitors to do.
Then close the loop so this does not repeat:
- Monitor expiry on every hostname, not only the apex. Alerts at 30 days and 7 days catch the silent cron failures.
- Keep the renewal timer enabled and dry-run it monthly.
- Check the redirect chain after any migration, because a stale HTTP to HTTPS rule pointing at a dead host produces the same dead end.
Pro Tip: Re-enabling the header after an outage? Start at
max-age=300, five minutes, confirm the certificate renews cleanly, then raise it toward 31536000. That short window is your rollback. Once a year-long policy is out in the wild, you cannot recall it.
If the page now loads but returns something else, the certificate work is done and you are onto a separate problem, such as a 403 Forbidden Error: How to Fix It (Step-by-Step 2026).
Your Next Step After an HSTS Error
Fixed it yourself? Lock in the part that prevents a repeat: automated renewal plus expiry alerts on every hostname, reviewed once a month. On a properly managed host that watching is support's job rather than yours, which is the quiet argument against self-managing certificates on a site that earns money. If you want it off your plate, start on the Economy plan at $1.99/mo, renewing at $1.99/mo, with Hostaccent's 99.99% uptime guarantee and a 30-day money-back window behind it. One honest limit: Economy is sized for a single site, so several projects belong on Standard. Still locked out? Open a ticket and you get the exact quote before any work starts.
Frequently Asked Questions
Can I bypass an HSTS error in Chrome?
Not on a site with an active policy. Chrome hides the Advanced and Proceed controls deliberately, and you cannot bypass the HSTS warning with the usual keyboard trick. Your only local option is deleting the stored entry at chrome://net-internals/#hsts, which works for dynamic entries and not for preloaded ones. On a live site, repairing the certificate is the real answer, since every other visitor stays blocked until you do.
How long does an HSTS policy stay in my browser?
Until max-age counts down, and it resets every time you load the site over working HTTPS. A common value is 31536000 seconds, one year, so a site you visit weekly effectively renews the policy forever. Clearing history or cache does not reliably remove it, because the policy store is separate from cookies and cache in both Chrome and Firefox. Deleting the entry directly is the dependable route.
How do I remove a domain from the HSTS preload list?
Serve a valid header without the preload directive, keep HTTPS working, then submit the domain through the removal form at hstspreload.org. Approval is not the finish line. The list ships inside browser binaries, so expect roughly 6 to 12 weeks before most Chrome users see the change, and longer for people on older versions. Plan removal months ahead of any migration that needs plain HTTP.
Does clearing the policy on my computer fix it for my visitors?
No. The change is local to one browser profile on one device. Customers keep hitting the same wall until the certificate at the origin is valid again. This catches out owners who clear their own browser, watch the site load, and assume the incident is over. Check from a device that has never visited the site, or from an external SSL checker, before you call it fixed.
Why does the site load on my phone but not my laptop?
Because the policy is stored per browser and per device. Your laptop has visited before and holds the rule, while your phone may never have received the header, so it shows an ordinary certificate warning with a proceed option instead. It makes a useful diagnostic: if only the devices with history are blocked, a stored policy is what you are dealing with.
Should I turn HSTS off after this?
No. Removing it strips real protection against downgrade attacks and cookie theft, and it fixes nothing at the certificate layer. Keep the header and repair the renewal process that caused the outage. If you genuinely need a plain HTTP subdomain, drop includeSubDomains rather than the whole policy, and leave the preload directive off until certificates have renewed hands-free for several months.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.