HSTS error in Chrome or Firefox: what it means and how to fix it

What the HSTS error means

An HSTS error is a certificate error on a site that has told browsers to accept HTTPS only. The site, or a parent domain, sent a Strict-Transport-Security header on an earlier visit, or is on the browser's built-in preload list. Now the browser has found a problem with the certificate, and because of HSTS it will not let the visitor carry on.

The wording varies by browser, but the important part is the same: there is no way through.

The HSTS part of the message is not the fault. It is the reason the visitor cannot bypass the fault. The fault itself is shown in the error code, such as NET::ERR_CERT_DATE_INVALID in Chrome or SEC_ERROR_UNKNOWN_ISSUER in Firefox, and that code tells you what to fix.

Why visitors cannot bypass an HSTS error

Without HSTS, a certificate warning has an Advanced or Accept the Risk option. That option is exactly what an attacker on public Wi-Fi relies on: present a fake certificate and hope the visitor clicks through. HSTS exists to close that gap, so browsers deliberately remove the option for HSTS sites. Nothing you put on the page can change this, because the browser stops before your page loads.

So the only real fix for an HSTS error on your own site is to fix the certificate problem underneath it. Telling visitors to clear their browser settings is not a fix: it removes their protection, it does not work for preloaded domains, and it is undone on their next visit when your site sends the header again.

If you are the visitor rather than the owner, and the error appears on a large site such as Google, the problem is almost certainly on your device or network. Large sites are preloaded and their certificates are monitored around the clock, so a genuine fault is rare. Check the causes in the visitor-side section below.

The usual causes and their error codes

The last row catches many site owners out. If example.com sends includeSubDomains, every visitor who has been to the main site also applies HSTS to staging.example.com, mail.example.com and anything else under the domain. A subdomain that always had a self-signed certificate, and was fine because people clicked through, suddenly cannot be opened at all.

The hostname mismatch guide and the untrusted certificate guide go into the second and third rows in more detail.

How to diagnose the HSTS error on your site

Test from outside your own network, using the exact host name visitors use. First see what certificate the server presents and whether it chains to a trusted root:

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>&1 \
  | grep "Verify return code"

Read the output like this:

• notAfter in the past means the certificate has expired.
• subjectAltName without the host you tested means a name mismatch.
• Verify return code: 0 (ok) means the chain is good. Codes 18, 19, 20 or 21 point to a self-signed certificate or a missing intermediate.

Then find where the HSTS rule comes from, so you know which hosts it covers:

curl -sI https://example.com/ | grep -i strict-transport
curl -sI https://www.example.com/ | grep -i strict-transport

If the apex shows includeSubDomains, every subdomain needs a valid certificate. Also check the domain's status on hstspreload.org. In Chrome, chrome://net-internals/#hsts lets you query a domain and see whether your own browser holds a dynamic rule for it.

If the error only appears on some devices, particularly older phones or some Android apps, suspect the chain. Some clients fill in a missing intermediate certificate by themselves and others do not, which is why a broken chain can look fine on your desktop.

Fixing the certificate on common servers and platforms

Expired certificates

For Let's Encrypt with Certbot, run a renewal and reload the web server, then check the renewal timer so it does not happen again:

sudo certbot renew
sudo systemctl reload nginx
systemctl list-timers | grep certbot

On Plesk, open SSL/TLS Certificates for the domain and renew the Let's Encrypt certificate, making sure it covers both the domain and the www alias. On cPanel, run AutoSSL from SSL/TLS Status.

Missing host names

Reissue the certificate with every host name visitors use, for example:

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com

Missing intermediate

Point nginx at the full chain file, not the leaf certificate on its own:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Cloudflare

Cloudflare's free Universal SSL covers the apex and first-level subdomains such as shop.example.com, but not deeper names such as eu.shop.example.com. A proxied deeper name produces a certificate error that HSTS makes impossible to bypass. Use an advanced certificate, or set that record to DNS only and give the origin its own certificate.

Subdomains that cannot have a certificate yet

If an internal host genuinely cannot run HTTPS for now, remove includeSubDomains from the parent and send max-age=0 to clear stored rules, as explained in the guide to disabling HSTS. Then add the certificate and restore the header.

When the cause is the visitor, not the site

If your certificate checks out from outside and only some people report the error, look at their side. These cause the same HSTS screen on perfectly healthy sites, including Google, banks and social networks:

• Wrong date or time. A device clock set months out makes every certificate look expired or not yet valid. Setting the time automatically fixes it.
• Antivirus HTTPS scanning. Some security software intercepts HTTPS with its own certificate. If its root certificate is missing or damaged, every HSTS site fails.
• Public and hotel Wi-Fi. Captive portals intercept the first request to show a login page, which looks like an attack to the browser. Opening an http:// address that is not preloaded usually brings up the portal.
• Workplace networks. Inspection proxies need their root certificate installed on each device.
• Old devices. Phones and computers that no longer receive updates may not trust newer root certificates.

The fix, step by step

Edge cases worth knowing

• Preloaded endings. Every site under some endings, including .app and .dev, is HSTS by default. A certificate problem on such a site always produces an unbypassable error.
• IPv6 and default sites. If the server has a separate IPv6 configuration without the right certificate, visitors on IPv6 get the default site's certificate and a name mismatch, while IPv4 visitors see no problem.
• Load balancers. One node with an old certificate causes intermittent errors. Test several times, or test each node directly.
• Clearing HSTS locally. Deleting the rule in your own browser lets you reach a broken site for testing, but changes nothing for visitors.

Keeping HSTS errors away

• Monitor certificate expiry for every host name, including subdomains, and alert at least 14 days before the end date.
• After every renewal, check the live certificate with openssl s_client, not just the file on disk, because a server that was not reloaded keeps serving the old one.
• Keep a list of every subdomain in DNS. Before adding includeSubDomains, confirm each one has a valid certificate.
• Use full chain files and test from a phone on mobile data as well as your desktop.

The SSL errors guide covers the wider set of certificate problems that sit underneath these warnings.