Opera 12.17 no longer works with https for me
-
Deleted User last edited by
So If I'm reading all this right there isn't a fix yet?
BTW I'm not able to connect to a site using a EV cert from GeoTrust, not a Cloudflare one here.
Does anyone else have any ideas or a workaround to bypass the error page?There is one: choose an updated browser.
-
Deleted User last edited by
Opera 12 had these SSL problems over a year and i think this will not be fixed.
So If I'm reading all this right there isn't a fix yet?
The fix is Opera 27.
-
stng last edited by
So If I'm reading all this right there isn't a fix yet? BTW I'm not able to connect to a site using a EV cert from GeoTrust, not a Cloudflare one here.
Are you getting the "fatal error (40)" ?
Does anyone else have any ideas or a workaround to bypass the error page?
Opera.dll patch (only in theory) could have fix the problem.
Or use a proxy service such as "kproxy" (description/instruction is above), but this is just a half measure and this method won't work with all web-sites.@sidneyneto
There is one: choose an updated browser.
You mean replace the browser with an another one?
@gwen-dragon
The fix is Opera 27.
Opera 27 is entirely different browser for a different audience of users
-
-
rseiler last edited by
@gwen-dragon, this particular problem only started last fall (any other earlier https problems were easily solvable).
It's too bad that Cloudflare continues to misrepresent Universal SSL:
https://www.cloudflare.com/ssl#browsers -
aberly last edited by
I can no longer reach theadminzone. Is there some change I can ask them to make that will let me us it?
Secure connection: fatal error (40) from server.
https://theadminzone.com/
Failed to connect to server. The reason may be that the encryption methods supported by the server are not enabled in the security preferences. -
blackbird71 last edited byA 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 last edited by
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 last edited by
@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=0Many 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 last edited by
@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 last edited by
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 last edited by
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 last edited by
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 last edited by
@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 last edited by
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 last edited by
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 last edited by
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 last edited by
So what is the problem exactly. The security the websites are using is too old or too new?
-
A Former User last edited by
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 last edited by
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.
