Safari suddenly can't connect to any HTTPS site because it "can't establish a secure connection".

This is on an administrator account, not a managed account.

A different administrator account is able to use Safari with HTTPS, so must be something specific to my account, but I have no idea what.

Google Chrome has no problems connecting to HTTPS sites.

Things I have tried:

  • emptied Safari's cache
  • deleted Safari's preferences
  • reset Safari entirely
  • repaired Keychain (no errors found)
  • deleted Keychain (didn't help)
  • repaired permissions in Disk Utility
  • rebooted
  • hoped it would suddenly fix itself

All of the google results I saw suggested either repairing the Keychain (which I tried and which did not help) or were only applicable if there were "Parental Controls" involved, which doesn't apply here.

If I had to guess, I would think that wherever Safari is checking for "certificates" is somehow corrupted, but I could be wrong. I'm not even sure where to look for those - maybe ~/Library/?

  • When I've had this problem in the past, it was because my system clock was set profoundly wrong. That's likely not your problem, but it's worth checking.
    – Daniel
    Commented Jun 12, 2012 at 23:51
  • Good thought! But nope, my Mac is synced with Apple's own time server.
    – TJ Luoma
    Commented Jun 13, 2012 at 13:47
  • @DanielLawson How could such behavior be related to the system clock?
    – gentmatt
    Commented Jun 13, 2012 at 21:01
  • @gentmatt I suspect it has to do with certificate expiration checking, but I don't know. I just know that I've had trouble with https connections in the past when my system clock was reset to 1970 and I hadn't noticed. In any event, that isn't the problem here.
    – Daniel
    Commented Jun 13, 2012 at 22:14
  • If you removed the revocation file then it suggests a cert was marked as expired at some point?
    – user52261
    Commented Jun 28, 2013 at 12:00

7 Answers 7


A report on forums.macrumors.com seems to be fairly similar to yours. This happens as well in Safari 5.1 and is very recent.

The solution was to delete:

  • 5
    YES YES YES! THANK YOU! I did not have that exact file but I had 'com.apple.security.revocation.plist' and when I deleted that file, Safari works again. THANK YOU!
    – TJ Luoma
    Commented Jun 13, 2012 at 22:07
  • I'm glad that this got solved :)
    – gentmatt
    Commented Jun 14, 2012 at 9:25
  • 2
    for me it was deleting everything in (I moved, rather than deleted) ~/Library/Preferences/com.apple.security.* Afterwards, I was able to connect to https:// websites again, and my laptop recreated ~/Library/Preferences/com.apple.security.cloudkeychainproxy3.keysToRegister.plist (one of the files I had moved).
    – Dannid
    Commented Jul 7, 2015 at 17:41
  • Beware deleting com.apple.security.* files. I found that in doing do, mdworker (Spotlight indexer) could no longer index my Outlook mail, which renders the search/filter function in Outlook totally useless.
    – user207988
    Commented Oct 26, 2016 at 22:37

This just reared its ugly head again, this time with Yosemite. It also affected all of the browsers I commonly use (Firefox, Chrome, Chrome Canary).

I tried to follow the advice here, which involved getting information about the root certificate used by the offending website via the web browser: How to fix: Safari can’t open the page because Safari can’t establish a secure connection

I got no love here, since every browser refused to negotiate a connection far enough to get the name of the certificate issuer. I even tried using open_ssl at the command line, but also it failed:

    [foo@bar]$ echo ^d | openssl s_client -connect broken.web.com:443 | tee cert.log
6480:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.40.1/src/ssl/s23_lib.c:185:

Finally, I was able to open the website on an old machine with Internet Explorer version 9, and found the name of the certificate authority: Comodo Certification Authority.

The linked article hinted at the right thing to do, but here's what worked for me:

  • Open the Keychain Access app.
  • Select "System Roots" keychain.
  • Search for the issuing certificate authority (in this case, Comodo).
  • View the certificate details (double click, expand the "Trust" area of the view window).
  • In my case, the trust rule was: "When using this certificate, ".
  • I changed it to "Always Trust", closed Keychain Access (after entering my admin password) and the page loaded.
  • Not wanting to leave it in a less secure mode, I used Keychain Access again and switched it back to "Use System Defaults".
  • Problem solved, no relaxation of security parameters.

YMMV but it's less drastic than nuking all your tweaks by eliminating the security preferences, nuking all your Safari data, or even re-installing your whole OS, as suggested by some of the links attempting to address this problem.

Update: I had to restart Chrome / Firefox for them to accept the "updated" / reset certificate preferences.

Another Possible Reason: Corporate Proxy or MITM

Just recently had a spate of these, along with failures of certain apps to connect to their servers via the network.

  • The symptom: Laptop or iPhone fails to secure a connection sometimes. The above method doesn't work.
  • The test: Run the iPhone or laptop using cellular connection or mobile hotspot instead of the suspected WiFi or wired network.
  • The result: If the cellular connection works and the non-cellular doesn't, then suspect a man-in-the-middle (MITM) attack, or a corporate proxy that looks like one.
  • I guess it doesn't mean much to anyone around here, but I have the same problem with freshly downloaded Safari for Windows (v5.1.7). Can't even open Apple's own URL: developer.apple.com/safari/tools
    – userfuser
    Commented Jan 15, 2017 at 11:59
  • Since it's not opening Apple's domain, I'll assume the root CA wasn't omitted with this update (why would they omit their own root CA?). I'd check any ISP / VPN / Corporate Network "security" measures. The corporate MITM often flakes out where I am, and then nothing secure connects, even with Chrome, Brave or Firefox.
    – rholmes
    Commented Jan 17, 2017 at 15:44

For me, it was a screwed up HSTS.plist. Removing that file solved that problem for me for multiple domains:

rm Library/Cookies/HSTS.plist

Then logout and login again (just restarting Safari won't do the job).

About HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

  • 1
    Or rm ~/Library/Cookies/HSTS.plist. I didn't even have to restart my browser. Pages loaded as soon as I deleted the file!
    – daviewales
    Commented Jan 15, 2019 at 6:04

I had a similar problem and found that the date on my computer was wrong and thereby all security website certificates were expired. I simply adjusted the date backwards and worked flawlessly. Kept saying cannot establish a secure connection (because the security tag was outdated on the website...) This also will effect all apps that use time/date such as email apps etc...


Deleting the ~/Library/Cookies/HSTS.plist file and restarting my browser worked for me.

  • I didn't even have to restart my browser. As soon as I deleted that file, pages started loading.
    – daviewales
    Commented Jan 15, 2019 at 6:03

Reviewing and changing the certificate trust settings appropriately in Safari worked well for me.

I had this "can't establish a secure connection" problem with HTTPS connections from Safari when I updated the self-signed certificate on a NAS.

The NAS forces HTTPS connections by choice.

I'd already connected via LAN to the NAS and encountered the certificates and told Safari to 'trust'.

Trying to connect via the NAS's DDNS look up gave the problem.

Checking the certificate trust settings showed the certificates were only trusted for the LAN IP. Easily changed.


Problem: Safari can't get secure connection. Solved: After going through other blogs, finally solved by deleting keychain log in password.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .