Previous 1 2 Next 15 Replies Latest reply: Feb 18, 2012 6:49 PM by srebby
mcandre Level 1 (0 points)



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.




Fix #1: Open Keychain 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||.


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..."




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 SuperUser.


By the way, while posting this bug, I found yet another. In the Apple Discussion editor, scrolling while selecting your product, MacBook version xx.yy.zz, doesn't bloody work. Apple Developers: TEST. YOUR. SH|T.

MacBook, Mac OS X (10.7.2)
  • Bruce Stewart Level 1 (20 points)

    Hi mcandre,

    Are you using a wi-fi portal, sometimes called a captive portal, to get to the internet?

  • mcandre Level 1 (0 points)

    Yes, I am located at George Mason University, where we must login to Mason SNAP before accessing the Internet.


    The 10.7.2 update may interact weirdly with the portal, but the problem is not limited to accessing the secure portal site: I can't visit GMail, or any SSL site for that matter, with Safari or Chrome. Finally, Keychain Access corrupts itself on every reboot.

  • Bruce Stewart Level 1 (20 points)

    Yes, I work at Brock University and we are having the same problem here. Many usinveristies and colleges are having the same problem all over. It is the portal actually. It is not allowing the certificate checking to happen. When these checks are blocked, Lion interprets this as a hijack of the captive portal and blocks all apps that use the Aplpe webkit from accessing the net. Your firefox is probably set to ignore OSCP and CRL checks and this bypasses the keychain to do this.

    What I am finding is, when the check can't happen because the portal blocks it, a bad key  called unkown shows up in the keychain. After this happens, you cannot even open the keychain app. it beachballs. If you boot from the recover drive (holding command + R) and then go to the disk utility, repair drive, and repair permissions; you can then reboot and get t the keychain.

    You can delete the bad certificate and all works well.

    For a few hours to a day or so. The next time you go to the portal after being timed out, it tries to check and you start all over again with the problem.

    What we have found is, when the portal allows the machine to get out to check whatever certs it needs to athenticate on the portal itself, the keychain does what it needs to do and then the machine works normally. You must not be the onyl person at your University with this problem in 10.7.2. Call your helpdesk and tell them to look it up. It is all over the forums now.

    The workarounds only work for a little while, allowing the certificate revokation checks at the portal seems to solve this. We have so far had no one coming to our helpdesk since we made this change this morning.

    I will follow this discussion and report back if anything changes.

    If you support people at the university want to know more about this issue, point them at



    That should get them on the right track.

  • ashley_anne Level 1 (0 points)

    I think I am having this same issue.  After waking up my MBP, it takes about 3-4 minutes for it to connect to a website in both Safari and Google Chrome.  Emails come in fine in Outlook as Wi-Fi is connected okay.  This delay just started happening when I updated to 10.7.2.  It doesn't matter what Wi-Fi I'm on as this problem occurs both at home and school.  Does this sound like the same issue you all are having?  

  • mcandre Level 1 (0 points)

    Bruce, thanks for identifying the problem. Indeed, it occurs when portals are used. But is Apple's fault for corrupting the keychain when portals block cert verification. Portals or no portals, that's no excuse for shoddy, insecure programming. ANYTHING can happen on the 'net, so you have to program with the expectation that servers will respond in surprising ways.

  • mcandre Level 1 (0 points)

    Why on earth can't I edit my previous posts? Bad Apple, no treat.

  • chusi Level 1 (0 points)

    same troubles here, this is a really serious issue. for now i'm hardly able ot use my mac anymore. apple please have a serious look at this!


    i checked with packet peeper and i can see that safari/chrome is connecting to the ssl server and the server is responding, but then obiously something goes wrong. afaik my keychain is set to ignore OSCP and CRL but i can't confirm it because i can't open keychain!!!

  • Scratchfury Level 1 (0 points)

    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 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:



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

  • chusi Level 1 (0 points)

    unfortunately i don't even have a captive portal here. independ of which wireless / wired connection i'm using, this problem still occures.


    after a reboot i can open keychain, but then as soon as i try to connect to certain HTTPS pages, keychain freezes up and the page times out. for some strange reason, sometimes i'm able to open one or two SSL encrypted pages until the problem happens. I also moved away my login keychain and created a new one and tested with another user on my mac book, still, always the same issue.


    it is also independent if i set OCSP/CRL to "Off" or "Best Attempt"


    i really really hope apple can resolve this quickly or somebody figures out a workaround!

  • Scratchfury Level 1 (0 points)

    It might be that your ISP has their DNS server to respond to all queries.  Like if you type in by accident, there should be no response to a DNS query, but your ISP might give one and send you to their search page.  In this case, keychain will try to get the OCSP/CRL info from a page which is not formated correctly.  I believe this is what is causing that bad certificate.  Apple needs to fix their parser so that it can realize the formating is not correct before it tries to add the certificate and crash the keychain.


    Try the Google DNS servers (, to see if it helps.

  • chusi Level 1 (0 points)

    thanks for the tip, i tried it but unfortunately doesn't work either.

    I did a trace with wire shark and i can see that the TLS negotioation phase seem to be successfull. at least it looks very much the same as if i do it with firefox, in which case it works.

    after the initial handshake phase, when the client should start to send the encryted payload, there's no more traffic and a timeout after about 20sec happens.


    i can also provide the dump if somebody think's it would be of some use.


    i just wonder if more people are experiencing the same issues? there are some posts which look similar, but most focus on to the captive portal part, which i still think doesn't really apply for my case. I'm also not connecting to random (wrong) https sites but to for example .


    many thanks again for your help

  • brazilianphysicist Level 1 (0 points)

    Yes, I'm experiencing this too (using 10.7.2). Not sure exactly when this started happening as I use Firefox most of the time, but now Safari+Chrome+most other services that use SSL hang.


    What is going on??

  • fotisp Level 1 (0 points)

    I was bit by this issue early on.


    I believe this has been the worst update ever. Of course being used to perfection (tiger,leopard,snow leopard) is weird that something like this creeped up.


    I am posting here to be notified if someone find a more permanent solution.


    There are some solutions in the links below:





Previous 1 2 Next