Opera 12.17 no longer works with https for me

blackbird71

blackbird71

A number of sites are using new certificates and encryption methods not available to Opera 12. As to why a given site refuses to work depends on what cert and encryption options it is offering, and what is available in Opera. No match-up, no connection. As @rseiler has noted, the situation has been compounded by Cloudflare's implementation of Universal SSL, low-cost certs and the problems created for accessing sites now using them, especially in older browsers.

While there are some creative file games or settings one can try to employ (as this and other threads describe), it's an ultimately losing battle to keep fighting against creeping obsolescence, especially in things related to security. The current web focus on protocol exploits like Poodle and others has created a lot of turmoil and change in the https realm at the server and cert levels, and woe to those having problems involving them.

mcortis

mcortis

check the date of the computer : if not in the interval of validity of the certificate, fatal error 1066 with Opera 12.17
I had put for tries (something else) the computer date at may 2015 and after I had lot of messages for non valid certificates in installed softs (Opera, IE, Safari).
Reput the good date and OK.

rseiler

rseiler

@blackbird, I'd love to hear your input on this new twist.

For several weeks now, I've been seeing some crushing CPU usage (lasting about a minute) bringing up a small minority of random sites for the first time in a given session. When I finally grew tired of it, I began the difficult process of troubleshooting by temporarily eliminating some low-hanging fruit that have caused problems in the past, like oversized dat files, icons directory, etc.

After failing miserably at that and essentially everything else I tried, I noticed that one of the pages causing it was wordpress.com and that it was https (all the problem sites were definitely not https, but maybe they involved related elements of some kind behind-the-scenes). So I then concentrated on the [Security Prefs] section of prefs. At first, I thought it was some horrible new variation on the SSL/TLS thing, but those settings don't seem to matter.

What does matter is this:
OCSP Validate Certificates=0

Many of us had set that to 0 due to the problems back at the beginning of the thread. It certainly did not have any adverse effect that I saw until this problem cropped up recently. Setting it to 1 solves the CPU problem.

With it back on 1, I tried revisiting some of the sites early in the thread that used to throw an error with it on 1, but they no longer are a problem. I'm not sure why, but it may have to do with updates made to the op*.dat files since last year. Even if certain sites still didn't work with it on 1 (and there may yet be some), that would be far better than having the browser come to a halt for a full minute while opera.exe burns the CPU.

blackbird71

blackbird71

@blackbird, I'd love to hear your input on this new twist.>
...

Online Cert Status Protocol (OCSP) is an alternative method to a Cert Revocation List (CRL) for ensuring that a secure website's cert hasn't been revoked, and requires the browser to contact a certificate authority (CA) to confirm that each https certificate the browser runs into is still valid. That typically requires a DNS look-up for the cert authority each time in addition to querying the CA and making the secure website connection itself. I know that in Firefox, if one is getting certain OCSP-related errors (such as "secure connection failed") , the remedy is to shut off OCSP in the FF settings. If Olde Opera is similar, probably setting OCSP Validate to 1 causes the browser to use the OCSP cert verification method instead of Opera's CRL, and that may cause more CPU activity to perform and track all the handshaking and checks involved, especially for multiple sessions tabs having multiple certs.

Back when the initial problems in this thread with certs were occurring, they may have been due at least in part to issues with Opera obtaining timely or accurate CRL responses from Opera for website cert revocation checks. Switching the OCSP to 1 may have remedied that by using an alternative revocation check that bypassed whatever issues the CRL process was having. If one had few open tabs (especially when starting from a stored session), the extra initial CPU loading at startup may not have been especially noticeable.

Some of this is 'logical' speculation on my part, since I'm not sure exactly how Olde Opera processes either CRL or OCSP verification paths internally, nor whether server/cert updates at sites and CA's have perturbed one or the other pathway that Opera uses.

rseiler

rseiler

OK, thanks.

Just to summarize for anyone coming back to this thread:

-If you never touched the OCSP setting in the first place, it's still enabled and you're done. It's easy to see: opera:config#SecurityPrefs|OCSPValidateCertificates

-If you did disable it, then it's highly likely that you want to re-enable because a) there seems to no longer be a need to disable it, and b) with it disabled, certain sites will now cause Opera to peg the CPU in an extremely noticeable way.

stng

stng

@rseiler

If you did disable it, then it's highly likely that you want to re-enable because a) there seems to no longer be a need to disable it, and b) with it disabled, certain sites will now cause Opera to peg the CPU in an extremely noticeable way.

Interesting...
Have you tried to enable(disable) OCSPValidateCertificates for certain web-sites via override.ini ?

A Former User

Hello,

I have read this thread, but not sure if there was a fix that was good for all sites with the https security issue. If so anyone care to elaborate.? Please no suggestions about upgrading to new opera. Thanks.

rseiler

rseiler

@stng, no I forgot again that you could do that. I would try it and test it out against sites that would cause Opera to buckle the CPU with OCSP enabled, but there's no call presently to have to fool with OCSP. It would have probably shown the same issue though.

@laingman, the only remaining issue that I know of is "fatal error (80) from server" from certain sites employing Cloudflare's services in a certain way, but there's no way to deal with it in Opera. Fortunately, I don't hit those sites often at all.

A Former User

Actually, I have seen both fatal error 80 and 40 for the same website. Another weird thing that I have seen once or twice is opera not recognizing links, sprint.com for example

rseiler

rseiler

Have you seen 40 lately? I think sites that would show 40 before now show 80, though maybe it depends on the Cloudflare implementation as to what # you get. Either way, it's the same bad news.

A Former User

Have you seen 40 lately? I think sites that would show 40 before now show 80, though maybe it depends on the Cloudflare implementation as to what # you get. Either way, it's the same bad news.

Yeah, saw 40 recently but 80 was first. Maybe because I started playing with the settings

A Former User

So what is the problem exactly. The security the websites are using is too old or too new?

A Former User

I have the Secure connection: fatal error (40) error message on https://addons.opera.com/addons/extensions/
That’s very annoying to not being able to install/update extensions… I don’t know any alternative.

I only have this error in my company (which firewall replaces each SSL certificate names by its own!)

rseiler

rseiler

I don't know why your company is doing that (or even how it's doing that), but maybe try using a VPN to visit that site. Or, if it's a laptop, take it home.

A Former User

There is not much I can do as when I’m home with this laptop, I can’t access anything (I mean, NO network) besides the company VPN through which I can then access the net as from Office (I mean, crippled, or even more crippled).
It’s super securited laptop of hell.

Maybe I can copy stuff from %userprofile%\AppData\Local\Opera\Opera\widgets from the home PC where I get extensions updated.
But maybe it’s enough as an off topic here.

A Former User

@mxxxw
The problem web-site hosted by Cloudfire, ins't?
Try to import chr... Opera's root certs to the Opera 12.

Download archive: https://app.box.com/s/5p00vediw04ds7xkxwgg
Close Opera
Extract archive to your Opera's profile folder (don't forget to backup all *.dat files before any manipulations). Replace(rewrite) original *.dat files with files from zip-archive.

This should fix the issue with Cloudfire/SSL !

I did the cert swap. Has no effect on the error 40. But it seems to have a positive effect on stability, not responding etc., I used to have problems with nypost.com and even this forum site.

I wonder how much work it is for opera to throw us another update to fix some security issues. Just to be nice.

A Former User

I have a solution which is good enough, way better than leaving my beloved old opera to open in another browser. I tried the Kproxy method but kproxy does not work on some sites. I will post this in any relevant thread that has to do with incomparability/security issues.

Reguires installation of neptune: http://www.meadco.com/Neptune/About. I edited my right click menu to run a script so that I am now able to open all the sites with error 40 and even the Chase bank site in Internet Explorer Issues: Normally something about error running script and the url does not display in the address bar, just about blank. And I can't figure out how to bookmark page or use auto login. I got this script from one of the old button creator sites.

Here is the script:

Item, View in IE=Go to page, "javascript:(function(){if(location.protocol.match(/^(javascript|about|opera):$/i))return;var l=location.href;var t=(document.getElementsByTagName('title')[0]?document.getElementsByTagName('title')[0].text:l).replace(/</g,'<').replace(/>/g,'>');var w=window.open('','_blank');w.document.documentElement.innerHTML='<head><title>'+t+' - using Internet Explorer rendering</title><style type=\x22text/css\x22>body{margin:0;padding:0;overflow:hidden;}embed{border:none;}</style></head><body><embed type=\x22application/x-meadco-neptune-ax\x22 width=\x22100%%\x22 height=\x22100%%\x22 param-location=\x22'+l+'\x22></embed></body>'})();",,"View in IE",View

anotheralex

anotheralex

Have you tried to enable(disable) OCSPValidateCertificates for certain web-sites via override.ini ?

I did and it works! Some site stopped working for me last week, throwing an error

'Secure connection: critical error (1066)'

and after adding the following line to a dedicated section in override.ini - I can access that site over https again:

SecurityPrefs|OCSP Validate Certificates=0

A Former User

and after adding the following line to a dedicated section in override.ini - I can access that site over https again:
SecurityPrefs|OCSP Validate Certificates=0

could you hint me: where's the "decicated section"? does it exist in every override.ini??

A Former User

.