OCSP works until it is needed. See in https://www.imperialviolet.org/2012/02/05/crlsets.html the comparison to the seat-belt. A hacker which can do a MITM attack (the main reason to have certificates), can block access to the OCSP server in all important cases. Thus without a warning that the OCSP server isn't reachable, OCSP is completely useless because it fails exactly when it is needed (someone is attacking you).

Most OCSP are getting pretty good with the uptime. See http://uptime.netcraft.com/perf/reports/performance/OCSP . I think a reasonable response of a user accessing a large e-commerce site, which is probably using a reliable CA, over a public wifi, is not enter a credit card if such a warning is shown. Very similar to the case where a site shows a self-signed certificate.

I don't think it should be a fatal error. Some CA's still have unreliable CAs. One could use the netcraft data to handle them differently, but adding that information to the warning. But even for the reliable CAs it is still possible to not have access to the OCSP server (e.g. firewall or captive portals). Opera should show a dialog similar to the one it shows for self-signed certificates. This lets the user decide whether the risk is reasonable.

Soft-fail is completely useless: https://www.imperialviolet.org/2014/04/29/revocationagain.html. The argument by netcraft (http://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.html) that at least CRL isn't useless without hard-fail isn't correct, because Opera doesn't cache CRLs between browser restarts. Thus Opera should either remove CRL/OCSP checks completely and add crlset (as Chrome - of course this means that no revocation checking is done for most sites not included in crlset), or should show some warning if the CRL/OCSP isn't accessible. As it is right now the revocation checking is simply broken and useless.

I created a test page to see how browsers behave: http://crt.rschulz.eu. It shows that Opera doesn't detect if the OCSP or CRL server is not reachable.

Opera should add an option, to opt-in into OCSP hard-fail. Firefox and Explorer allow this configuration and I think that it makes sense in the wake of heartbleed. An error to connect to the OCSP server should either produce an error message or at least a warning (similar to mixed content).
For background:

• http://arstechnica.com/security/2014/04/how-heartbleed-transformed-https-security-into-the-stuff-of-absurdist-theater/
• http://security.stackexchange.com/questions/55457/how-to-configure-browser-to-detect-revoked-certificates
• http://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.html

With the heartbleed bug many site certificates are revoked and correct checking of revocation is particular important. I would like to know how exactly Opera handles the certificate revocation check.

• Do you cache CRL lists. If so for how long and is there a way to refresh them on demand? If a CRL cannot be downloaded do you use the cached copy?
• Do you support CRL lists in all formats (e.g. both binary and text-based)?
• Do you treat a failure if checking for revocation failed? Do you treat it as a failure for any reason ( e.g Connection error to both CRL and OCSP, only one provided and connection error to that, unknown format, ..)?
• Do you utilize both CRL and OCSP. If so which is the default one? And how is decided whether the other is used as fallback. What if the fallback fails too? Are you using any other methods like crlset? If you only support only one of the methods what if the certificate only supports the other?
• Do you do CRL/OCSP checks on all intermediate certificates?
• Is it possible to get a warning for any certificate which is older than 04/07?

I think it be great if you created a blog post in the context of the heartbleed bug and describe exactly how Opera is handling revocation.