Fix: Safari Can't Establish Secure Connection on Mac

You're trying to log into your bank or your company's portal and Safari just throws 'Safari can't establish a secure connection to the server' at you with zero useful detail. Annoying, especially when Chrome opens the same site fine.

Here's the fix. Run through these in order — most people are back online after step 2.

The fix

1. Check your Mac's date and time first

This is the one people skip and it's the most common cause. If your Mac's clock is off by more than a few minutes, every SSL certificate looks expired or invalid. I've seen this happen after a laptop sits in a drawer for a month, or after a CMOS battery goes in an older iMac.

Open System Settings → General → Date & Time. Make sure 'Set time and date automatically' is on and the time zone is correct. If it's already on, toggle it off and back on to force a resync.

Then check it from the terminal to be sure:

sntp -sS time.apple.com

That forces a sync with Apple's time server. If it returns a big offset in seconds, that was your problem.

2. Quit Safari completely and clear the cached site data

Not just closing the window — quit Safari with Cmd+Q. Then:

Reopen Safari
Safari menu → Settings → Privacy → Manage Website Data
Search for the domain that's failing (e.g. example.com)
Remove it

Half the time Safari is choking on a corrupted HSTS entry or a stale pinned certificate for that one domain. Wiping the site data forces a fresh handshake.

3. Flush DNS and check your DNS servers

Bad DNS can hand Safari a bogus IP for the site, and then the cert doesn't match. On macOS Sonoma and Sequoia:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Then check what DNS you're on: System Settings → Network → your active connection → Details → DNS. If you're on your ISP's DNS or some sketchy free resolver, switch to Cloudflare (1.1.1.1) or Quad9 (9.9.9.9) and test again.

4. Check the certificate in Keychain Access

If the site uses a self-signed or internal cert — pretty common for company intranets and dev environments — Safari will refuse it unless the cert is trusted in Keychain. Open Keychain Access → System Roots (and also login keychain), search for the issuing CA, and check if it's expired or marked 'Not Trusted'.

If it's an internal cert your IT team gave you, double-click it and set 'When using this certificate' to 'Always Trust'. You'll be prompted for your password.

Why this works

Safari is stricter than Chrome and Firefox about certificate validation. It uses Apple's own trust evaluation, and it caches trust decisions per-domain. When people say 'it works in Chrome but not Safari', what's usually happening is Chrome is quietly accepting a marginal cert (expired by a day, wrong hostname on a wildcard, SHA-1 signed) that Safari flatly refuses. Apple's trust store is also updated independently of the browser, so a CA can get revoked in a macOS point release and suddenly every site using that CA breaks in Safari only.

The clock thing matters because TLS validates certs against 'now'. Off by ten minutes on a freshly issued cert with a ten-minute clock skew and the handshake fails.

DNS matters because SNI (Server Name Indication) sends the hostname in the clear during the handshake. If DNS is poisoned or hijacked, you connect to the wrong server, the cert doesn't match the hostname, and Safari bails.

Less common variations

Only one site fails, everything else works

That site's cert is probably actually expired or misconfigured. Check with:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

If the 'notAfter' date is in the past, it's the site's problem, not yours. Nothing you do client-side will fix it. Wait for them.

VPN or corporate proxy interference

Some corporate VPNs and antivirus tools do SSL inspection — they swap the real cert for their own. If IT didn't push the inspection root cert to your Mac, Safari will reject every HTTPS site while Chrome might accept it if Chrome has its own trust store. Disconnect the VPN and test. If it works, your IT team needs to push the root cert.

After a macOS update

Apple periodically revokes CAs in point releases. If everything broke right after a macOS update, check Settings → General → Software Update for a companion security response, and reboot. Sometimes the trust store update needs a restart to apply.

Old macOS, new TLS requirements

If you're still on Catalina or Big Sur, some sites now require TLS 1.3 or modern ciphers your OS doesn't support. Safari will report a secure connection failure. The real answer is updating macOS, not fighting it.

Keychain is corrupted

Rare, but if everything above fails, your login keychain might have issues. Open Keychain Access → Keychain First Aid (hidden in the menu, hold Option) or just create a new login keychain. Back up first — this nukes saved passwords.

Prevention

Leave 'Set time and date automatically' on. Always.
Run macOS security updates. Apple's CA revocations ship there.
Don't install random root certs to 'make the warning go away'. Read what you're trusting.
Use a decent DNS resolver (Cloudflare or Quad9) — it avoids a whole class of these problems.
If you're a dev working with self-signed certs, use mkcert instead of hand-rolling certs. Safari trusts it without argument.

Ninety percent of the time it's the clock or a stale HSTS entry. Fix those two and you'll stop seeing this error entirely.