Phones and operating systems
SSL errors on hotel, airport and café Wi-Fi (captive portals)
Connect to Wi-Fi: The network you are using may require you to visit its login pageCertificate 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 shows a valid certificate:
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:
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 / NET::ERR_CERT_AUTHORITY_INVALID |
| Firefox | 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 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.
FAQ
Is it safe to accept the certificate warning on hotel Wi-Fi?
No. You cannot tell the portal's certificate apart from an attacker's on the same network. Open an http:// page to reach the login instead, and after logging in, the real sites will load with valid certificates.
The login page never appears on my laptop. What can I do?
Disconnect any VPN, turn off custom or encrypted DNS settings temporarily, then open http://example.com in a new tab. If that still fails, forget the network and reconnect; some portals only redirect the first request after joining.
I logged in but still get certificate errors. Why?
Some networks keep intercepting HTTPS for filtering, or your session expired. Check whether the certificate issuer is the network operator. If it is, avoid entering sensitive data on that network, or use mobile data.