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