| |||||||||||||
Fraudulent *.google.com certificate issuedFraudulent *.google.com certificate issuedPosted Aug 30, 2011 21:51 UTC (Tue) by raven667 (subscriber, #5198)In reply to: Fraudulent *.google.com certificate issued by paravoid Parent article: Fraudulent *.google.com certificate issued
As someone who has a hand in a captive portal deployment what we've done is whitelist the IPs of the OCSP servers for the certs we are using to work around this problem so we don't have helpdesk complaints from customers who have OSCP enabled. A cron jobs can check to see if the IPs have changed.
(Log in to post comments)
Fraudulent *.google.com certificate issued Posted Aug 31, 2011 16:34 UTC (Wed) by cesarb (subscriber, #6266) [Link]
Did you also whitelist all the needed DNS servers? When on untrusted networks, I usually run the bind DNS server on my laptop (querying directly the root servers) so it can validate the records using DNSSEC.
Fraudulent *.google.com certificate issued Posted Aug 31, 2011 18:03 UTC (Wed) by raven667 (subscriber, #5198) [Link]
No, the only dns servers allowed through the captive portal prior to authentication are the recursive ones we maintain, these are what are suggested via DHCP. I imagine your config would break on a lot of captive portals unless they had blanket rules allowing any dns traffic.
|
|||||||||||||