Some wi-fi networks require viewing and agreeing to terms before Internet access is allowed. When my MBP connects to such a network, it attempts to redirect and isn't able to connect. I tried all browsers. However, it works when I boot up Windows on my Mac. Why does it do this? I don't think my /etc/hosts file is messed up. Could anyone give me some insight?
I am using Lion 10.7.2.
I had this problem connecting to the local public library system network. The problem seems to be a result of my having specified DNS servers ((i.e. OpenDNS, Google, etc.)) in my Network preferences. The solution was to create a network location called "No DNS" which doesn't have any DNS servers defined and use that network location when I need to log into these networks.
The issue we've identified here at our university has to do with security fixes Apple added in 10.7.2 to prevent a security vulnerability.
When you connect to a wifi network your machine attempts to contact http://www.apple.com/library/test/success.html to determine if there's a captive portal in the way. If it fails to get back a "Success" it believes that it's been intercepted. You can read about this process in detail if you wish, but it's not pertinent. The popup is leveraging a concept called WISPr.
What was discovered was that there were ways to do an attack on systems this way that tricked users into thinking they were accepting a software install/download from Apple. So now, before that popup shows, the system attempts to check the certificate revocations to verify the popup being shown isn't a fake one.
The problem is that not all captive portal systems allow connection to the hosts the machine needs to get to in order to do the verification. If it hijacks their DNS returns then you get this endless failure to proceed.
There's four possible ways to cope with this.
One requires the people at the captive portal to cope with this (or unbreak their stuff, depending on your outlook) by opening up the capture so Lion can talk to the necessary servers:
crl.usertrust.com ocsp.usertrust.com crl.incommon.org ocsp.incommon.org
The second option seems like a horrible one to me: turn off OCSP and CRL. Don't do it. I'm not going to help you do it. It's a recipe for never revoking corrupted or compromised certificates.
The third option is to alter your own machine so that efforts to connect to the above servers simply fails rather than being intercepted by the captive portal. The solution I read suggested updating your hosts file to redirect the above hosts to 127.0.0.1 Since you're presumably not running a certificate authority this will allow the check to error out quickly. However this seems likely to be the same effective result as turning off OCSP. I recommend against it.
The fourth option is the most specific and what I did. I added the certificate for my organization's specific captive portal and told it to always trust it. The solution was specified here and I didn't create it, but here it is reproduced for completeness:
Export the captive portal's SSL certificate with the following steps:
Visit the captive portal page in Firefox Select Tools > Page Info > Security > View Certificate > Details > Export Save the certificate to your hard drive with the extension ".crt" You can import the certificate with the following steps:
Open Keychain Access.app Drag the certificate from Finder into a keychain Double click on the certificate and expand the "Trust" section Choose "When using this certificate: Always Trust" Close the popup window.
Some folks reported corrupted keychains from this problem; I have not had that issue but 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.
I went to Network Preferences, selected the hotel's Wi-Fi name > Advanced > DNS. There I removed the DNS value filled in with the little minus icon and it worked!
My library wouldn't let me login until I created a "new location" in the network system preferences window. After that, it worked like a charm!
