Safari OCSP/CRL Checking Causing Connectivity Failure I'm currently implementing an 802.1X network authentication system using Cisco ISE for one of our customers.

Our solution requires users (with personal devices) to connect to an open SSID network, get HTTP redirected to our (https, internally signed) login portal, and get provisioned with a wireless profile.

This is working fine in general, but we have a specific case with OS X machines (so far it's only been seen on Mavericks) where browsing to a website and getting redirected is not working. It is only happening in Safari, in Firefox it is working fine.

We have allowed traffic to the OCSP and CRL servers specified in our HTTPS server certificate, however, in a packet capture from the Mac, I can see it sending AAAA DNS requests for the OCSP and CRL servers names (which are failing, because IPv6 is not configured/supported on this network), but the machine does not appear to fallback to IPv4 (A) requests.

Other DNS lookups (safari looking up google.com.au) send simultaneous AAAA and A lookups.

Is this a known bug? Is there anything on the network side we can do to resolve this issue?

I am interested to hear if there is a config change on the Mac we can make to fix this, but it is not a solution, as we need to make as minimal a change to the users personal devices as possible.

Thank you.
So... There was another thing causing my portal to not load (redirect ACL). The DNS was a red herring, and the only reason we saw AAAA and not A requests was because the machine had already cached the answer for the A record.

Finding that out was humbling... what a silly mistake!

Anyway, no issue with the Mac here, but if you see similar behaviour, flush your DNS cache and try again!