# SSL errors on hotel, airport and café Wi-Fi (captive portals)

> Public Wi-Fi login pages intercept HTTPS and cause certificate errors until you sign in. How to reach the login page safely on laptops and phones.

Source: https://ssl.sh/errors/captive-portal-ssl-error/
Last updated: 2026-11-10

**Certificate errors on public Wi-Fi usually mean you have not completed the network's login page yet.** Until you sign in or accept the terms, the network intercepts your requests and tries to redirect them. For HTTPS sites that redirect cannot be done with a valid certificate, so the browser shows a warning instead of the login page.

## Is it the site or your device?

Neither: it is the network. A quick check: the same site works on mobile data, and the [SSL checker](https://ssl.sh/tools/ssl-checker/) shows a valid certificate:

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

If several unrelated HTTPS sites fail with name-mismatch or untrusted-issuer errors right after joining a Wi-Fi network, assume a captive portal. Do not accept the warnings; get to the login page instead.

## Causes

### 1. You have not logged in yet

The portal answers every connection until you authenticate. Opening a plain HTTP page lets it redirect you cleanly:

```text
http://example.com
```

### 2. Automatic portal detection did not trigger

Phones and laptops check a known HTTP address after joining a network and open a sign-in window if they are redirected. A VPN, a custom DNS resolver, or encrypted DNS can prevent that check. Disable them briefly, then reconnect.

### 3. The browser opens an HTTPS or HSTS site first

Your home page or a reopened tab is an HTTPS site, often protected by HSTS, so the portal cannot redirect it. Chrome sometimes recognises this and shows its "Connect to Wi-Fi" page with a button to open the login.

### 4. Session expired

Many portals log you out after a few hours or when the device sleeps. The errors return until you log in again.

### 5. Network keeps intercepting after login

A few networks filter HTTPS even after login. If the certificate issuer is the network operator, treat the network as untrusted.

## What it looks like on each device

| Device | What you see |
|---|---|
| Chrome / Edge | "Connect to Wi-Fi" page, or [NET::ERR_CERT_COMMON_NAME_INVALID](https://ssl.sh/errors/net-err-cert-common-name-invalid/) / [NET::ERR_CERT_AUTHORITY_INVALID](https://ssl.sh/errors/net-err-cert-authority-invalid/) |
| Firefox | [SSL_ERROR_BAD_CERT_DOMAIN](https://ssl.sh/errors/ssl-error-bad-cert-domain/), sometimes with a banner offering to open the network login page |
| iPhone / iPad | A sign-in sheet appears automatically; Safari shows "This Connection Is Not Private" if it does not |
| Android | "Sign in to Wi-Fi network" notification |

## How to get online safely

Opening a plain http:// page lets the portal redirect you to its login page without a certificate warning.

**1. Open http://example.com** (not https) in a new tab, or use the system's sign-in notification.

**2. Disconnect VPN and custom DNS** until you are logged in, then turn them back on.

**3. After logging in,** reload the original site. If it still shows a certificate error, check the issuer; the [HSTS page](https://ssl.sh/errors/hsts-cannot-bypass/) explains why some sites refuse to load at all.

## How site owners fix it

Nothing on your server needs to change when `curl ssl.sh/example.com` shows a valid certificate. Network operators should implement the Captive Portal API (RFC 8908) and the DHCP/RA option (RFC 8910) so devices can find the login page without intercepting HTTPS at all.