sfw/fix
Safari — secure connection high

Safari Can’t Establish a Secure Connection to the Server

Safari or iOS rejected the TLS handshake, usually over an untrusted, expired, hostname-mismatched, or incomplete certificate chain.

What you see

Safari Can’t Establish a Secure Connection to the Server
Safari can’t open the page “https://example.com” because Safari can’t establish a secure connection to the server “example.com.”

What’s actually happening

The page won't load and Safari gives one terse line with no detail about why. The same URL frequently works in Chrome or Firefox, which is the tell that this is Safari/Apple-specific — Apple's Secure Transport and App Transport Security are stricter about chain completeness and minimum protocol/cipher than other stacks. On iOS you often get an even shorter message. The error covers several distinct root causes behind one string.

Common causes

  • Missing intermediate certificate — the server sent only the leaf. Chrome can sometimes fetch the missing intermediate via AIA; Safari is far less forgiving and just fails.
  • The cert is expired, not yet valid, self-signed, or issued for a different hostname (no matching SAN entry).
  • App Transport Security rejects the connection because the server only offers TLS 1.1/1.0, a weak cipher, or no forward secrecy — ATS requires TLS 1.2+ with specific ciphers.
  • The device's date and time are wrong, so a valid cert reads as expired or not-yet-valid. Common after a battery pull or on a freshly reset device.
  • A captive portal, content filter, or TLS-intercepting proxy is injecting its own cert that the device doesn't trust.

How to fix it

  1. Check the date and time firstSettings → General → Date & Time → Enable 'Set Automatically' on iOS, or the equivalent on macOS. A clock that's off by months is the single most common cause and the fastest to rule out. Re-test after fixing.
  2. Test the chain with an external checkerRun the host through SSL Labs (ssllabs.com/ssltest) or `openssl s_client -connect example.com:443 -servername example.com </dev/null` and read the certificate chain. 'Chain issues: Incomplete' or a verify error 'unable to get local issuer certificate' means you're missing an intermediate — that's usually the Safari-specific failure.
  3. Install the full intermediate chain on the serverDeploy fullchain.pem (leaf + intermediates), not just the leaf cert. With Let's Encrypt use `fullchain.pem`, not `cert.pem`. In nginx the `ssl_certificate` directive must point at the combined file. Reload and re-test on SSL Labs until 'Chain issues' clears.
  4. Raise the TLS protocol and cipher floorIf SSL Labs shows TLS 1.0/1.1 or weak ciphers, enable TLS 1.2 and 1.3 and a modern cipher suite with forward secrecy. ATS won't connect otherwise from an app, and Safari flags it. Disable RC4/3DES and SSLv3 entirely.
  5. Rule out the networkSwitch the device from Wi-Fi to cellular (or vice versa). If it works on one network and not the other, a captive portal or intercepting proxy is the culprit, not the cert. Forget the Wi-Fi network or sign in to the portal page directly.

Stop it recurring

Serve the full chain and keep your TLS config at 1.2+ with forward-secret ciphers, then verify on SSL Labs after every cert renewal.

Related errors