One way to tackle captive network connection errors in OS X

When you connect your Mac to a network, if you receive a proper configuration such as an IP address and DNS servers from your router then you should be able to use Mail, Safari, and other networking client programs to access various services either on the local network or through the Internet. However, sometimes it can happen that despite a seemingly healthy connection you aren't able to access Web pages and e-mail.

Recently MacFixIt reader Tom ran into such a situation with a university network:

We have a MacBook Pro mid-2012 release running 10.8.2. The computer is connected to Michigan State's wireless network when this happens (not our AirPort Router). The MBP will have a valid IP address. However, Safari, Chrome, Mail will not work.

While it is not uncommon for odd configuration issues in a system such as caching or other handling of the network settings to cause problems with some connections, the troubleshooting steps tried by Tom in this situation did not show any change in behavior or results that indicated the source of the problem:

• The system always seems to have an IP address that is from the university system when the MBP can not connect. So it is not like the system is making a wireless connection elsewhere.
• Pinging something like 8.8.8.8 (Google's public DNS) or Facebook's IP results in the packets come back with no losses.
• We have tried to flush the DNS via dscacheutil -flushcache
• We have tried to plug in via an ethernet cable, however the ethernet adapter is not registered so that could be the issue. Of course there is a Wi-Fi IP address, but no connectivity.
• We have tried a PRAM reset
• We tried to clean up a number of misc wireless networks that were registered (though not in use).
• The system seems to have better success in some locations than others, but the Airport Express needs unplugged and plugged back in all the time.
• The firewall on the Mac is Off
• We have manually set the MTU to 1300 in System Preferences > Network > WiFi > Advanced > Hardware > Manually > MTU: Custom > 1300

Despite all of these checks and settings changes, the system continued to still receive an IP address but block access to services. As a result, my recommendation to Tom was to manually clear out the system's network configuration files and have it recreate them from scratch, to ensure that the configuration files would be built properly and would not be a source of the problem. However, when Tom did this it did not affect the problem at hand, suggesting the cause lay elsewhere.

On many university and corporate networks, IT departments add layers of security to network connections, which sometimes are a matter of supplying log-in credentials but also which may use certificates and other security features to validate the connection, so even if your system is getting valid IP address information it still may be prevented from accessing network services.

This ended up being the case in Tom's situation: the university's captive portal network was not being configured properly on the Mac system. Captive portal networking is a common method for supplying open network access to organization members, in which upon connecting you are presented with a Web page where you supply log-in credentials. The page then configures a certificate that is used to maintain the connection so you can access the Internet through other programs besides your Web browser.

To gain access to the portal the Wi-Fi network will issue an IP address, so the system will appear to be properly connected, but without proper authentication handling the connection will still be blocked.

In Tom's case the certificate was not being set up properly in OS X, which may be from a bug in the latest version of the OS or from how the university has its captive portal configured, so the fix for this problem was, as outlined in this StackExchange discussion, to extract the certificate and put it in the system's keychain.

In order to do this, Tom had to open Firefox and get to the captive portal log-in page, followed by going to the Tools > Page Info > Security > View Certificate > Details window and then choosing the Export function to save the certificate as a ".crt" file. Importing this in the keychain involved opening the Keychain Access utility and dragging the certificate from the Finder into the log-in or system keychain.

Once imported, double-clicking the certificate opened its settings, and expanding the Trust section revealed how the system would handle it. Under this section, selecting Always Trust when using the certificate allowed unhindered use of it for establishing the connection to the university's network.

If you have similar problems with connections through captive portal networks, then you might take a look at the certificate being used and see if similarly importing it into your system's keychain helps overcome the problem.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.