HSTS Error: Why You Cannot Bypass It and How to Fix It

"HSTS error" is not a separate error code. HTTP Strict Transport Security (RFC 6797) lets a site tell browsers, through the Strict-Transport-Security response header or the built-in preload list, to use only HTTPS for a set period. While that policy is active, the browser rewrites http:// links to https:// before sending them (Chrome DevTools shows a "307 Internal Redirect"), and RFC 6797 requires that any certificate or TLS error ends the connection with no user recourse.

So the real problem is a certificate or handshake error such as NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_AUTHORITY_INVALID or NET::ERR_CERT_COMMON_NAME_INVALID. HSTS only changes the outcome: Chrome removes the "Proceed" link and explains "You cannot visit example.com right now because the website uses HSTS." HSTS itself is working as designed; the certificate is what needs fixing.

On the server side: an expired certificate, a missing intermediate, or a hostname that the certificate does not cover. includeSubDomains is a frequent trap: once the parent domain sends it, every subdomain must have a valid certificate too, including internal and staging hosts with self-signed ones. Preloaded domains and whole preloaded TLDs such as .dev and .app are HTTPS-only in browsers before the first visit.

On the visitor side: a wrong system date, a hotel or airport captive portal that intercepts HTTPS, antivirus HTTPS scanning, or a corporate proxy whose root certificate is not installed. On ordinary sites these show a warning you could click through; on HSTS sites they are a hard stop.

HSTS can be set in two places: by your origin, or by Cloudflare under SSL/TLS > Edge Certificates > HTTP Strict Transport Security (HSTS). With Cloudflare proxying, visitors see Cloudflare's edge certificate, so the edge must cover every hostname you serve. The risk comes later: if you pause Cloudflare or switch a record to DNS-only, browsers that cached your HSTS policy now validate the origin's certificate directly, and a self-signed or Origin CA certificate there fails with no way past it.

On nginx, send the header only on HTTPS responses and include always so error pages carry it too:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Ramp max-age up gradually; add includeSubDomains only when every
    # subdomain has a valid certificate
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Use fullchain.pem, not cert.pem, so the intermediate is sent. Browsers ignore an HSTS header received over plain HTTP.

1. Find the real error. openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null and read Verify return code.
2. Check dates and names. openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName.
3. Renew or reissue. With Let's Encrypt, certbot renew then reload the web server; make sure the new certificate covers every hostname, including www.
4. Repair subdomains under includeSubDomains. Give each subdomain a valid certificate, or stop sending includeSubDomains and wait for cached policies to expire.
5. To retire HSTS, send Strict-Transport-Security: max-age=0 over valid HTTPS; each browser forgets the policy on its next visit. A preloaded domain needs the removal form at hstspreload.org, and the change takes months to reach users.

Check that your device's date, time and time zone are correct. Then try another network: if you are on hotel or airport Wi-Fi, complete the portal login on a plain HTTP site first. Pause the HTTPS or web-scanning feature of your antivirus and disconnect from the VPN or corporate proxy, then retry.

Clearing the browser cache does not help: the certificate is checked live and HSTS is stored separately. For a domain you control, such as a development host, Chrome lets you delete a dynamic policy at chrome://net-internals/#hsts under "Delete domain security policies"; preloaded entries cannot be deleted. In Firefox, "Forget About This Site" in the history usually clears it. Do not do this for sites you do not own: the block may be protecting you from interception. If the error appears for everyone, only the site owner can fix the certificate.

curl -sI https://example.com/ | grep -i strict-transport-security
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep 'Verify return code'
# expect: Verify return code: 0 (ok)

Test every hostname covered by includeSubDomains, not only the main site. The SSL/TLS checker shows expiry, chain and name coverage, and the security headers check shows the Strict-Transport-Security value you are sending.

• ERR_CERT_DATE_INVALID
• ERR_CERT_AUTHORITY_INVALID
• ERR_CERT_COMMON_NAME_INVALID
• ERR_TOO_MANY_REDIRECTS
• HSTS guide
• HSTS preload guide