Opera 12.17 no longer works with https for me
-
blackbird71 last edited byThere may be a clue to what's involved in the transitory cert-approval behavior in this Opera statement (from http://www.opera.com/docs/ca/ ) :
"Newer versions of Opera (14 and higher) use the root store provided by the operating system and the list of EV-enabled roots maintained by Google. Older versions of Opera (versions 9.5 through 12) use Opera's online root store. Until fall 2013, the online solution was built on Opera's root store program, but after that it is based on NSS by Mozilla.
To get certificates to be accepted by Opera, roots should be part of the above-mentioned root store programs."
Consequently, it's conceivable that no matter what a user does to fiddle with the cert files, Opera goes online to check the online store and negates whatever has been altered, or at least part of what's been altered.
-
rseiler last edited by
Yet that check doesn't affect browsers where those permissions originated, such as 11.64 and 12 alpha. How can that be? Maybe some sort of signature within the approved certificate in Opera that ties it to that particular installation of Opera?
-
blackbird71 last edited by
It's also possible that the coding within Opera was altered around the onset of version 12 in those areas that handle the online certs and handshaking, so that it might work differently in some way(s) from older versions - intentionally or otherwise. If it was intentional, it might or might not be apparent from knowledgeable, detailed examination of change logs; if it wasn't intentional (or was an overlooked byproduct of some other issue-focused logged change), there would be no visible record.
-
-
A Former User last edited by
Now add thepiratebay.se to the list.
I really hope this was meant to be tongue-in-cheek!
-
iamjohngalt last edited by
That's right, thepiratebay.se no longer works with Opera 12.17, 1863.
Secure connection: fatal error (40) from server. -
stng last edited by
That's right, thepiratebay.se no longer works with Opera 12.17, 1863. Secure connection: fatal error (40) from server.
It has problematic Cloudflare's SSL cert.
We need a working opera.dll patch. It's probably possible to prevent the blocking of a cloudflare's certs by Opera 12.x.
-
ppnsteve 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?
-
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 by
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 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 ?
