13

Summary

After updating from 10.7.1 to 10.7.2, neither Safari nor Google Chrome can load GMail. Spinning Beachballs all around.

The problem isn't GMail; Firefox loads GMail just fine.

The problem isn't limited to Safari or Google Chrome; Other applications also have trouble with SSL: Gilgamesh and Safari. Any program that uses WebKit (Google Chrome, Safari) or a Cocoa library (Gilgamesh) to access the Internet has trouble loading secure sites.

The various forums online suggest a handful of fixes, none of which work.

Analysis

Fix #1: Open Keychain Access.app and delete the Unknown certificate.

The 10.7.2 update also prevents Keychain Access from loading. The Keychain program itself Spinning Beachballs.

Fix #2: Delete ~/Library/Keychains/login.keychain and /Library/Keychains/System.keychain.

This temporarily resolves the issue, and lets you load secure sites, but a minute or two after rebooting or hibernating somehow magically undoes the fix, so you have to delete these files over and over.

Fix #3: Delete ~/Library/Application\ Support/Mob* and /Library/Application\ Support/Mob*.

There is a rumor that the new MobileMe/iCloud service ubd is causing the issue. This fix does not resolve the issue.

Fix #4: Open Keychain Access, open the Preferences, and disable OCSP and CRL.

This fix does not resolve the issue.

Fix #5: Use the 10.7.0 -> 10.7.2 combo installer, rather than the 10.7.1 -> 10.7.2 installer.

When I run the combo installer, it stays forever at the "Validating Packages..." screen. The combo installer itself is bugged to He||.

http://speely.files.wordpress.com/2011/10/validating-packages.png

I force-quit the installer, ran "sudo killall installd" to force-quit the background installer process, and reran the combo installer.

Same problem: it stalls at "Validing Packages..."

Recap

The only fix that works is deleting the keychains, but you have to do this every time you reboot or wake from hibernate. There is some evidence that ubd continually corrupts the keychain files, but the suggested ubd fix of deleting ~/Library/Application\ Support/Mob* and /Library/Application\ Support/Mob* does not resolve this issue.

Evidently, something is corrupting the keychain over and over and over.

Also posted on the Apple Support Communities.

Improve this question
3
  • some problem here on my MacBookPro and my iMac27, but it only occurs when I'm activating WiFi. As long as I work only over LAN everything is fine. Have to stay with 10.7.0 as long as this problem is not solved :-(
    – Thomas Hübner
    Oct 24, 2011 at 8:14
  • Not trying to "me too" here, but gmail works fine for me in 10.7.2 and safari 5.1.2. What kind of add-ons are you running in Safari? Glims, click2flash, etc?
    – skub
    Jan 16, 2012 at 23:46
  • Is this fixed in 10.7.3?
    – Tyilo
    Feb 8, 2012 at 3:39

9 Answers 9

Reset to default
2

Might I add that MobileMe is now iCloud so the folder is not Application Support/Mobi*, but rather Application Support/Ubiquity.

Delete that, though I had mixed results. It only worked 1/3 times. The way that definitely works is deleting:

~/Library/Keychains/login.keychain and /Library/Keychains/System.keychain

Just rinse and repeat. I'm not completely certain when the Keychain Access will break, but at some point (typically about 3 days in for me) everything stops working.

Firefox seems to get around things and if you don't want to do anything at all, you can turn off OCSP in Firefox (about:config) just to login to your wireless portal, and then remember to turn it back on. This won't fix Safari or Chrome though (what's the word on Opera?)

But the best solution is to restore to 10.7.1 or 10.7. I happened to have the DMG file from earlier and it was 10.7.1. Doing a "reinstall" only copies your Lion system files over and keeps your entire install in shape. So you're really just reinstalling the OS but keeping ALL your apps and data. So far this has been perfect. Just remember not to update to 10.7.2 if you're going to roll back.

Improve this answer
2
  • SSL sites that did not work for me with Safari or Chrome worked for me with Firefox, just by using that browser instead.
    – RyanWilcox
    Nov 18, 2011 at 21:50
  • It's because Firefox uses a different authentication method than Safari or Chrome. However it's not 100% reliable for me on 10.7.2. Sometimes I can bring up the login page for my captive portal at school. Other times I can't. The safest way is to roll back to 10.7.1. I've been on 10.7.1 for about 3 weeks now compared to 1+ month with 10.7.2 and it's night and day. No more constant rebooting and deleting files to get stuff to work. Let's hope 10.7.3 fixes things.
    – qwerasdf
    Nov 28, 2011 at 9:12
1

Our Mac support person has had success running DiskWarrior to fix the problem. None of his customers have reported the issue popping back up so far.

UPDATE:

I've figured out a fix. The issue is happening because the captive portal replies to EVERYTHING. I adjusted the captive portal's DNS to give bad results for OCSP and CRL sites. I used 127.0.0.1 in this case. The requests now timeout instead of giving back incorrect data. It also works locally by changing "/private/etc/hosts" and adding entries like this:

127.0.0.1    crl.usertrust.com
127.0.0.1    ocsp.usertrust.com
127.0.0.1    crl.incommon.org
127.0.0.1    ocsp.incommon.org

The correct entries may depend on the CA for the certificate. I found these addresses while watching the connection using Wireshark.

Improve this answer
2
  • Would Disk Utility or Onyx help, or does it have to be DiskWarrior?
    – mcandre
    Oct 26, 2011 at 17:26
  • @mcandre We are still trying to figured out what DiskWarrior does to fix the problem. It isn't obvious from the log files it produces.
    – Joseph
    Oct 26, 2011 at 18:23
1

After weeks of frustration with this constantly recurring problem (and waiting for Apple to release a fix), I decided to look for any solution that would rollback from the 10.7.2 update. Unfortunately I didn't find any way of doing a rollback to 10.7.1 or 10.7.0.

I therefore decided to use the Lion Recovery and see how it affects the situation. I performed the recovery procedure by following the steps outlined in this Apple support article.

I'm happy to inform now that in my case, the problem has (hopefully) disappeared! For some reason, even though the Lion Recovery process reinstalled OS X back to the 10.7.2 version, I haven't had any problems with Keychain or SSL for over a week now.

I used the online recovery mode and it seems that the OS X version that is downloaded during the recovery process does have some sort of setup that doesn't corrupt the keychain. The Lion Recovery process was super smooth and I did not have to reinstall any apps or recover files from backup (I would still recommend doing backups). My MacBook Pro is version 5,1.

This is the first time for me that Apple's security update has broken OS X in such a big way. I still wonder why they haven't released a fix/update to correct this issue.

Improve this answer
1
  • Update: Lion Recovery does not provide a permanent fix. I was able to use Safari/Chrome for few weeks when the problem reoccurred. So I'm sad to report that this doesn't provide a permanent fix as I hoped :(
    – Pyry Liukas
    Dec 14, 2011 at 7:54
1

(YMMV but it worked for me) -- I deactivated the network, rebooted to kill the keychain problem or else it freezes the Keychain Access, no need to delete anything. Then, I deactivated the OCSP and CRL. I activated the network ... I connected to my captive portal, and then reactivated everything.

Problem is the captive portal requires a certificates, but blocks the certificate chain. Thank you for the other one suggesting this.

Improve this answer
1

In my experience this happens only when connecting behind a captive portal. I think the reason is that the operating system tries to validate the certificate of the captive portal's login page, but the validation process requires internet access. I was able to fix this problem by manually adding the certificate of the captive portal page to the keychain and marking it as always trust.

You can export the certificate with the following steps:

  1. Visit the captive portal page in Firefox
  2. Select Tools > Page Info > Security > View Certificate > Details > Export
  3. Save the certificate to your hard drive with the extension ".crt"

You can import the certificate with the following steps:

  1. Open Keychain Access.app
  2. Drag the certificate from Finder into a keychain
  3. Double click on the certificate and expand the "Trust" section
  4. Choose "When using this certificate: Always Trust"
  5. Close the popup window

If you cannot open Keychain Access because your keychain is corrupted, turn off wireless, delete ~/Library/Keychains/login.keychain and /Library/Keychains/System.keychain, and then reboot.

Improve this answer
0

I found the problem. It's caused by the security fix in 10.7.2 (Security Captive Portal Hijacking). It's likely that one of the networks you are connected to has a portal site, where you can enter login data... for me it was the WiFi network.

To solve this issue for now, deactivate all networks, reboot, start keychain, go to preferences, certificates, turn OCSP and CRL off. Reboot, activate your networks and there you go...

Improve this answer
1
  • 1
    Thanks, but disabling OCSP and CRL don't work for me. Also, the keychain keeps corrupting itself.
    – mcandre
    Oct 24, 2011 at 21:17
0

Turning Off OCSP and CRL checks is avery bad idea. Essentially you are saying you don't care about certificate revocation. This is not good given the number of certificate authorities getting hacked these days. It is why apple upgraded it's security for captive portals. The problem is in the captive portal connection itself. If you go to one, you cannot check for CRL or OCSP because (duh!) you are in the captive portal. Whomever provides this portal, must also poke holes in their firewall to allow you out from the captive portal to check the certificates that the https captive portal page is giving you. We had to do this on our enterprise wireless system before Lion could get anywhere.

Improve this answer
0

I succeeded by doing "fix#2" as above.

In Terminal:

$ cd /Users/[username]/Library/keychains
$ remove login.keychain

and then reboot.

Improve this answer
1
  • 2
    Or, for the currently logged-in user: cd ~/Library/keychains. Also, I don't know where your remove command came from, but that is non-standard. rm login.keychain works on any Mac.
    – Arjan
    Dec 4, 2011 at 11:37
0

A suggestion at the end of https://discussions.apple.com/thread/3430739?start=0&tstart=0 seems to indicate that the following procedure fixes the issue: http://www.macworld.com/article/163227/2011/10/fix_a_lion_file_opening_hang_in_mac_os_x_10_7_2.html

Improve this answer
1
  • 2
    Welcome to Super User! It would be nice to include the essential parts of the answer here, and provide the link only for future reference.
    – slhck
    Jan 17, 2012 at 9:04

You must log in to answer this question.

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