# "You cannot visit this site right now" (HSTS): how to fix

> Chrome blocks certificate errors on HSTS sites with no bypass. Why it happens, what visitors can safely check, and how owners and developers fix it.

Source: https://ssl.sh/errors/hsts-cannot-bypass/
Last updated: 2026-11-10

**This message means the site has told your browser to always require a valid HTTPS certificate (HSTS), and the certificate it presented failed a check.** Because of HSTS, Chrome and Firefox remove the "Proceed anyway" option. The certificate problem underneath, not HSTS itself, is what needs fixing.

## Is it the site or your device?

Usually the site's certificate is broken; HSTS only removes the bypass. Test the site independently with the [SSL checker](https://ssl.sh/tools/ssl-checker/):

```bash
curl ssl.sh/example.com
```

- **The checker shows a certificate problem:** the site must fix it; as a visitor, wait.
- **The checker shows a valid certificate:** the cause is on your side. The usual suspects are a wrong system date, antivirus HTTPS scanning, a company proxy and public Wi-Fi portals. Click the error code on Chrome's page (for example `NET::ERR_CERT_DATE_INVALID`) to see which check failed, then follow that error's page.

## Causes

### 1. The site's certificate is broken

The certificate is expired, lacks a hostname or lacks an intermediate. HSTS turns what would be a click-through warning into a hard block. See [NET::ERR_CERT_DATE_INVALID](https://ssl.sh/errors/net-err-cert-date-invalid/) and [NET::ERR_CERT_COMMON_NAME_INVALID](https://ssl.sh/errors/net-err-cert-common-name-invalid/).

### 2. Interception on your device or network

Antivirus HTTPS scanning, corporate SSL inspection and captive portals present their own certificates. On HSTS sites, any untrusted interception is blocked outright. See [captive portal errors](https://ssl.sh/errors/captive-portal-ssl-error/) and [corporate SSL inspection](https://ssl.sh/errors/corporate-ssl-inspection/).

### 3. Wrong system clock

A date far in the past or future makes valid certificates look invalid. Fix the time.

### 4. Development host on a preloaded TLD or domain

Developers using `*.dev`, `*.app` or a subdomain of a preloaded company domain with a self-signed certificate hit this immediately, because those names are HSTS-preloaded in every browser.

### 5. HSTS set for a host that later lost HTTPS

If a domain once sent `Strict-Transport-Security` and later dropped HTTPS (or moved to a host without a certificate), returning visitors are blocked until `max-age` expires.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge | "Your connection is not private" with "You cannot visit example.com right now because the website uses HSTS" and no Proceed link |
| Firefox | "Did Not Connect: Potential Security Issue", saying the site uses HSTS and an exception cannot be added |
| Safari | "This Connection Is Not Private" without the option to visit anyway |

## How site owners fix it

Fixing the certificate removes the block; HSTS itself needs no change.

**1. Fix the certificate.** Run `curl ssl.sh/example.com`, then renew, add missing names or serve the full chain.

**2. Set HSTS deliberately.** Only send it once HTTPS works on every subdomain you include:

```nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
```

Check your header with the [HSTS checker](https://ssl.sh/tools/hsts-checker/).

**3. For your own development domains,** delete dynamic HSTS entries: in Chrome open `chrome://net-internals/#hsts`, enter the domain under "Delete domain security policies"; in Firefox, use History > right-click the site > "Forget About This Site". Preloaded entries cannot be removed this way.

**4. Preload removal takes months.** Removing a domain via hstspreload.org only takes effect after browsers ship updated lists, so only preload when you are sure every subdomain will keep HTTPS. Background: [how HSTS works](https://ssl.sh/learn/hsts/).