Why does a site work in Chrome but Safari can't establish a secure connection?

Because Apple enforces certificate rules that Chrome doesn't, and vice versa. The one that catches people is certificate lifetime: since September 1, 2020, Apple platforms reject any publicly-trusted TLS certificate whose validity period is longer than 398 days. A certificate issued for two or three years is perfectly valid to some clients and dead on arrival in Safari. Apple also requires Certificate Transparency — the certificate must carry Signed Certificate Timestamps proving it was logged publicly — and a minimum of TLS 1.2. So a server with an over-long cert, a cert that was never logged to CT, or an old TLS-only stack can hand Chrome a working page while Safari refuses the handshake. It's not a Safari bug; it's a stricter policy.

The error happens on every website in Safari, not just one. What does that mean?

When Safari can't establish a secure connection to essentially every HTTPS site, the problem is almost always on your Mac or iPhone, not on the servers. The top three: a wrong system clock (a certificate is only valid between two dates, and if your device thinks it's 2019 or 2035, every cert looks expired or not-yet-valid), software that intercepts TLS locally — antivirus 'web protection,' a corporate proxy, or a content filter that inserts its own certificate — and a broken or hijacked DNS/VPN setup. Fix the clock first, because it's the most common and the easiest to rule out. If it's one specific site that fails while everything else loads, the evidence points the other way: at that site's certificate or server.

Does 'Safari Can't Establish a Secure Connection' always mean a certificate problem?

No — it's a catch-all for any failure to complete the TLS handshake, and the certificate is only one of the possible causes. The same message appears when the server and Safari share no common TLS version or cipher (an old server stuck on TLS 1.0/1.1, which Apple deprecated in 2020), when a network device silently drops the connection mid-handshake, or when the site is reached over a hijacked DNS answer that lands you on the wrong host entirely. The wording sounds certificate-specific but the underlying event is broader: Safari tried to build an encrypted channel and something in the chain — clock, certificate, protocol, or network — refused. The job is to figure out which.

Safari Can't Establish a Secure Connection: Fix

Problem

Safari shows “Safari Can’t Establish a Secure Connection to the Server” and refuses to load the page. Sometimes it’s one site; sometimes it’s every HTTPS site you touch. The message sounds like a certificate problem, but it’s really Safari’s generic way of saying the encrypted handshake failed — and the handshake can fail for a clock that’s wrong, a certificate that breaks one of Apple’s rules, a protocol mismatch, or a network device sitting in the middle. The trick is not to guess. It’s to figure out whether the fault is on your device or on the server, because those are two completely different repairs.

Symptoms

The full error: “Safari Can’t Establish a Secure Connection to the Server.”
The same page loads fine in Chrome or Firefox on the same machine — or, tellingly, it doesn’t.
On iPhone/iPad the wording is similar; on macOS you may also see a certificate warning sheet you can (dangerously) click through.
It started after a date change, a new antivirus/VPN, a network switch, or joining a café/hotel Wi-Fi.
Curl or openssl s_client to the same host from a terminal succeeds, pointing the finger back at the client.

The First Question: Every Site, or One Site?

This single split decides everything, so answer it before touching any setting.

Every HTTPS site fails. The servers of the world did not all break at once. Something on your device or your network is poisoning every handshake. Look local:

The clock. A TLS certificate is only valid between a “not before” and a “not after” date. If your Mac or iPhone has the wrong date — a dead clock battery, a manually-set time, a bad time zone after travel — every certificate on earth looks either expired or not yet valid, and every connection fails. Set date and time to automatic and retry. This is the most common cause and takes ten seconds to rule out.
Local TLS interception. Antivirus suites with “HTTPS scanning” or “web shield,” corporate proxies, and parental-control filters work by intercepting your TLS and presenting their own certificate. If that inserted certificate isn’t trusted (or the tool is misbehaving), every site fails. Disable the TLS-scanning feature and test.
DNS or VPN. A hijacked or broken resolver, or a VPN routing you through something that mangles connections, can break the handshake before the certificate even matters. Try a different network, or turn the VPN off, to isolate it.

One specific site fails. Now the evidence points at that site’s certificate or server, not your Mac. Move to the next section.

When It’s One Site: Apple’s Stricter Rules

Here’s what surprises people: a certificate that works in Chrome can be rejected by Safari, because Apple enforces requirements other clients don’t. Three of them do most of the damage:

The 398-day limit. Since September 1, 2020, Apple platforms distrust any publicly-trusted TLS server certificate valid for more than 398 days. If an admin installed a long-lifetime certificate (some internal CAs still issue two- or three-year certs), Safari refuses it outright while older or more permissive clients shrug and accept it.
Certificate Transparency. Apple requires publicly-trusted certificates to prove they were logged to public CT logs, by carrying Signed Certificate Timestamps. A certificate issued outside that process — or by a private CA that skips CT — fails in Safari. (Chrome has its own CT enforcement, so this one often breaks in both; see NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.)
TLS 1.2 minimum. Apple deprecated TLS 1.0 and 1.1 across its platforms in 2020. A server that only offers those old protocols has nothing Safari will negotiate, and you get the secure-connection error instead of a version-specific one. The Chrome equivalent is ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

The other classic single-site causes are the ordinary certificate failures: an expired cert, a name mismatch, or a missing intermediate certificate in the chain (the server serves only its leaf, so Safari can’t build a path to a trusted root). Those show up across browsers too — the Chrome label is NET::ERR_CERT_AUTHORITY_INVALID and Firefox’s is SEC_ERROR_UNKNOWN_ISSUER. If Safari is uniquely unhappy while other browsers load the site, suspect the 398-day rule or CT first, because those are the Apple-specific ones.

Diagnose with DechoNet

SSL Check inspects the site’s live certificate the way a browser does — reading the expiry dates, the full chain, the validity period, and whether the intermediate is being served — so you can see in one pass whether the certificate is expired, over the 398-day lifetime, or missing a chain link. That directly separates “Safari is being strict about a real certificate flaw” from “my Mac’s clock is wrong.”
DNS Check confirms the hostname resolves to the address you expect. If every site fails and you suspect a hijacked resolver, check what the name actually points to here before blaming the certificate.

Resolution Checklist

Set date, time, and time zone to automatic on the affected device. Retry before anything else.
Determine scope: does the error hit every HTTPS site or one? Every site → look at clock, antivirus TLS scanning, DNS/VPN. One site → look at that certificate.
Disable any antivirus “HTTPS/SSL scanning” or “web protection” feature and test — this is the top cause of all-site failures on otherwise-healthy machines.
For a single failing site, run it through SSL Check: confirm the certificate isn’t expired, isn’t valid for more than 398 days, and serves its full intermediate chain.
Test the same host from a terminal: openssl s_client -connect example.com:443 -servername example.com. If that succeeds while Safari fails, the problem is in Safari/macOS trust settings, not the server.
Clear Safari’s cache and website data, and disable Safari extensions one at a time — a misbehaving extension can break TLS for specific sites.

When to Escalate

If SSL Check shows a certificate that’s expired, over 398 days, or missing its intermediate, the fix belongs to whoever runs the server — they need to reissue with a compliant lifetime, log it to CT, or install the full chain. A client can’t repair a server’s certificate.
If every browser but Safari loads a site and SSL Check reports the certificate as valid and CT-logged, the remaining Apple-specific suspect is the protocol or a cipher Apple no longer accepts; the server operator needs to enable TLS 1.2+ with a modern cipher suite.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.