# Safari "This Connection Is Not Private": iPhone and Mac fixes

> Safari shows "This Connection Is Not Private" when a certificate check fails. How to see the real reason on iPhone, iPad and Mac, and how to fix it.

Source: https://ssl.sh/errors/safari-this-connection-is-not-private/
Last updated: 2026-11-10

**"This Connection Is Not Private" means Safari could not verify the website's certificate and stopped before loading the page.** Unlike Chrome, Safari does not print an error code, so the first step is to find out which check failed. The cause can be the site, your iPhone or Mac, or the network you are on.

## Is it the site or your device?

Most often it is the site's certificate or a public Wi-Fi login page; an outside check tells them apart. Check the site independently with the [SSL checker](https://ssl.sh/tools/ssl-checker/), from any computer:

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

- **The checker reports a certificate problem:** the site must fix it.
- **The checker passes:** the cause is your device or network. Turn off Wi-Fi and try again on mobile data. If it works, the Wi-Fi network is intercepting or redirecting traffic; if it still fails, check the date and installed profiles.

To see Safari's reason, tap Show Details, then "view the certificate" (on Mac, click Show Certificate). Messages such as "expired", "does not match" or "signed by an unknown authority" map to the causes below.

## Causes

### 1. Expired certificate or wrong date

If the certificate is expired, the site must renew. If the date on your device is wrong, every site fails: on iPhone, go to Settings > General > Date & Time and enable Set Automatically. See [wrong system clock](https://ssl.sh/errors/wrong-system-clock-ssl-error/).

### 2. Public Wi-Fi login page

Hotel, airport and café networks intercept HTTPS until you log in. Wait for the login sheet to appear, or open Settings > Wi-Fi and tap the network name. See [captive portal errors](https://ssl.sh/errors/captive-portal-ssl-error/).

### 3. Hostname mismatch

The certificate does not cover the name you opened (for example `example.com` vs `www.example.com`). Only the site can fix it.

### 4. Untrusted issuer or extra profile

The issuer is a self-signed certificate, a private company CA, or a profile installed for a VPN, ad blocker or school or company management that intercepts traffic. Review Settings > General > VPN & Device Management and remove profiles you do not need.

### 5. Certificate breaks Apple's rules

Apple rejects certificates without SAN entries, with RSA keys under 2048 bits, with SHA-1 signatures, or (if issued after 1 September 2020) valid for more than 398 days. These mostly affect internal and homemade certificates.

## What it looks like on each device

| Device | What you see |
|---|---|
| iPhone / iPad Safari | "This Connection Is Not Private", with Show Details and Go Back |
| Mac Safari | Same title; Show Certificate reveals the reason |
| Chrome on iPhone | Uses Apple's verifier; shows Chrome's "Your connection is not private" |
| Chrome / Edge on desktop | ["Your connection is not private"](https://ssl.sh/errors/your-connection-is-not-private/) with a NET:: code |

## How site owners fix it

A complete chain and a certificate that meets Apple's rules fix it for all Apple devices.

**1. Test like Safari does.** `curl ssl.sh/example.com` reports expiry, SAN entries, chain and key size.

**2. Serve a complete, compliant certificate.** Full chain, every hostname in the SAN list, RSA 2048+ or ECDSA, SHA-256 signature, lifetime within current limits (200 days for certificates issued from 15 March 2026). With certbot:

```bash
sudo certbot --nginx -d example.com -d www.example.com
```

**3. Fix the chain** with the [chain builder](https://ssl.sh/tools/chain-builder/) if Safari on older devices fails while newer ones work.

**4. For internal sites,** deploy your company CA through an MDM profile so devices trust it without user action.