Currently Being ModeratedOct 26, 2011 12:20 PM (in response to Bruce Stewart)
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.
Currently Being ModeratedOct 26, 2011 12:33 PM (in response to mcandre)
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.
Currently Being ModeratedOct 26, 2011 12:58 PM (in response to mcandre)
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?
Currently Being ModeratedOct 26, 2011 4:16 PM (in response to Bruce Stewart)
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.
Currently Being ModeratedOct 27, 2011 12:34 AM (in response to mcandre)
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!!!
Currently Being ModeratedOct 27, 2011 11:59 AM (in response to mcandre)
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:
The correct entries may depend on the CA for the certificate. I found these addresses while watching the connection using Wireshark.
Currently Being ModeratedOct 28, 2011 12:51 AM (in response to Scratchfury)
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!
Currently Being ModeratedOct 28, 2011 5:20 AM (in response to chusi)
It might be that your ISP has their DNS server to respond to all queries. Like if you type in http://www.disnaylannds.com/ 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 (220.127.116.11, 18.104.22.168) to see if it helps.
Currently Being ModeratedOct 28, 2011 3:02 PM (in response to Scratchfury)
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 https://www.apple.com .
many thanks again for your help
Currently Being ModeratedOct 29, 2011 2:33 PM (in response to chusi)
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??
Currently Being ModeratedNov 11, 2011 9:57 AM (in response to mcandre)
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:
Currently Being ModeratedDec 6, 2011 1:14 PM (in response to mcandre)
I posted my solution to this on SuperUser: http://superuser.com/questions/349740/mac-os-x-lion-10-7-2-update-breaks-ssl/365 333#365333