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.

  • Please clarify "I tried all browsers" in your question by listing the browser applications by name.
    – bneely
    Commented Jan 27, 2012 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
    Commented Jan 30, 2012 at 16:48
  • I submitted an edit to add the term "sign-in page" to the title. Does that help?
    – bneely
    Commented Jan 30, 2012 at 19:19
  • I think that's a good title. Thanks for your consideration.
    – jaberg
    Commented Jan 30, 2012 at 19:52
  • DNS issue resolved it for me as well. I just spent about 1 hr looking for answers and none worked. I tried disabling Captive, running it directly, nothing. Thanks so much
    – user135307
    Commented Jul 7, 2015 at 16:46

4 Answers 4


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.

  • You mean to tell me these public wifi services rely on name resolution to call up the acceptance dialog? Ouch. Commented Jan 24, 2012 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
    Commented Jan 25, 2012 at 1:00
  • 1
    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
    Commented Jan 25, 2012 at 1:37
  • That is correct. Your first request will be redirected.
    – Shane Hsu
    Commented Aug 11, 2013 at 15:38
  • If you happen to be logged in with multiple users, log all of them out but one. I was logged in with two users and when I switched to the other one, the wifi spot login window appeared.
    – wrightak
    Commented Aug 7, 2015 at 11:46

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.


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!

You must log in to answer this question.

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