This is the scenario: At the airport, attempting to get online using their wireless network. I'm using firefox 2.0 and have OCSP verification for certificates turned on. The server that I'm trying to connect , has SSL turned on. And its SSL server certificate has an OCSP URL for verification purposes. firefox attempts to connect to the OCSP url to verify the certificate. But its unable to because its blocked by the wireless network, because I haven't paid for the connection yet. The error message I get is : "Error trying to validate certificate from secure.sbc.com - corrupted or unknown OCSP response - Error Code - 8063" Since the connection to internet is blocked until I pay for the connection, the local wireless network , returns a login page as the OCSP response.

I am having a similar problem. I have OCSP enabled by default and am trying to connect to my browser's "home page", which is an ssl-enabled site. I am sitting in a hotel that has free WiFi but you are required to read their network Terms of Service agreement before you can connect to the Internet. FireFox is throwing an alert "sb-ssl.google.com has sent an incorrect or unexpected message. Error code: -12263. (OK)" Two things: 1) We are displaying an error to the user that makes no sense and offers no explanation or advise. 2) We are reinforcing the bad behavior in users to click "OK" in error messages (because it's the only choice in this instance!). A savvy user will see the "SSL" and think there's a security problem. As we enable OCSP by default this will be an even more frequent (and therefor frustrating) user experience. Suggestion: the OCSP component should first verify that the user's Internet connection is working completely and correctly before interpreting OCSP responses as "incorrect".

I believe the situation has improved for most users. Although we check OCSP by default, we have switched to lenient mode, where we ignore nonresponding OCSP servers. However, I suspect the situation is still the same when using the strict OCSP setting.

This bug is still present as of Firefox 3.6.4. When user is behind a captive portal (which responds to all outgoing HTTP requests (aside from a whitelist) with a 302 redirect) the OCSP server is seen as responding (with that 302). The usual user experience is: 1) Page that triggers OCSP check takes extremely long (~10 seconds) to load. 2) When the user finally logs in, most captive portal sites will redirect the page rendered on screen to an error page (generated by the OCSP server). Suggestion: I don't know if a 302 is a valid response to a OCSP request. If it's not, once the client gets a 302, it should stop the OCSP process. Alternatively, perhaps the OCSP client could use a much lower redirect if the OCSP response is a redirect.

OCSP timeout in these cases should be 2 seconds (or 10 if your homepage is EV). I think the underlying implementation has changed to where this wouldn't be a problem any more, but if anyone can reproduce, please reopen this bug.