Take the 2-minute tour ×

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.

share|improve this question
Please clarify "I tried all browsers" in your question by listing the browser applications by name. –  bneely Jan 27 '12 at 3:03
@bneely I concur that your edit to this question makes it technically more correct (I considered a similar edit) but it also means "laypersons" searching for a solution must know what a captive portal is. Respectfully suggest you reconsider--or rephrase to include both technical and common terms. –  jaberg Jan 30 '12 at 16:48
I submitted an edit to add the term "sign-in page" to the title. Does that help? –  bneely Jan 30 '12 at 19:19
I think that's a good title. Thanks for your consideration. –  jaberg Jan 30 '12 at 19:52
add comment

2 Answers

up vote 12 down vote accepted

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.

share|improve this answer
You mean to tell me these public wifi services rely on name resolution to call up the acceptance dialog? Ouch. –  Jason Salaz Jan 24 '12 at 23:26
I don't presume to tell you anything–but it certainly seems as if this is the case (at least for some networks.) –  jaberg Jan 25 '12 at 1:00
Yep, they generally hijack your first DNS query, and point it to a server running a transparent redirect. It is indeed very crude. –  Fake Name Jan 25 '12 at 1:37
That is correct. Your first request will be redirected. –  Shane Hsu Aug 11 '13 at 15:38
add comment

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

share|improve this answer
add comment

Your Answer


