Opera 12.17 no longer works with https for me
-
rseiler last edited by
OK, so with that we're very close now, I think. Looking at 11.64, when you visit any of the above sites you're presented with one or two certificate error dialogs that allow you to approve and remember the given certificate.
The reason for all this seems to simply be a certificate name mismatch, which Opera (correctly) deems suspicious. For example, instead of the certificate matching the site's name, it's something like "ssl2000.cloudflare.com."
The question is: Why doesn't Opera 12 present the same dialog? Is there an option to enable that feature? If so, problem solved.
The next-best thing would be to export the "approved" certs from 11.64 and import them into 12, but Opera balks at that upon import in 12.17, even when exported from 12.00-1312 (arc.opera.com/snapshot/windows)
This seems to me a much simpler problem to solve than what we thought previously, that Opera was missing some important security feature like ECDSA. That never made sense to me when Cloudflare's own support page resolutely claims that Opera 8(!!!) and higher are compatible with Universal SSL.
-
stng last edited by
In my Opera 12.14, I tried to put(replace) opssl6.dat and optrust.dat files that i get from the 12.00-1312 after approving Cloudflare's certificates from a few problem web-sites. It's works, but for a very short time :(. Then Opera 12.14 removes these "extraneous" and weak certificates automatically from its memory and from the opssl6.dat file :(. Opera stops to recognize these certs.
The only working solution i've found - using a kproxy (free web-service) that helps to open a problem sites with a Cloudflare-issued certs in Opera 12. I wrote a special keyboard shortcut and macros that allows to do it as quickly as it possible in the address bar and in the main browser window.
1.How it works:
-
When i typing an URL in the address bar (for an example dabr.eu, that have Cloudflare-issued certificate), i press Alt+Enter shortcut. Then this site opens through the KPROXY, bypassing problems with SSL.
-
When i press Alt+F1 (outside the address bar, elsewhere in browser), Opera loads the current URL through the KPROXY. This can be used for a new, unknown web-sites with a "weak" Cloudflare cert.
2.How to set this up:
-
Go to web-site www.KPROXY.com
-
Click with right mouse button on the search filed, choose "Create Search..."
-
Set the keyword as KP, press OK
-
Go to Preferences - Advanced - Shortcuts - Keyboard setup - Edit
-
In the "Advanced" -> "Address dropdown widget" section create the new keyboard shortcut ("New..")
a)Set the value in the first column: Enter alt
b)Set the value in the second column: Go to line start & Insert,"kp " & Go
-
In the "Application" section create the new keyboard shortcut ("New..")
-
a)Set the value in the first column: F1 alt
b)Set the value in the second column: Go to page, "kp %u"
-
"Ok" - "Ok"
-
-
rseiler last edited by
One weird thing about moving the couple cert files over (I think opuntrust and optrust are the two main ones for this) is that the sites DO show up in Manage Certficates/Approved, but that isn't enough to make them work (you're at least getting it to work for a short time). There's obviously some other cubbyhole in Opera where the permission for the given site is stored, and we're somehow missing it.
Anyway, nice idea about the proxy. I'll try it.
Meantime, I'm thinking of opening another thread asking about Opera 12.17 not presenting a permission dialog when a site's certificate doesn't match the domain like Opera 11.x and early test builds of 12 did. This seems to be something they later decided against showing, but it would be nice to know if that's the case and whether there's an obscure option to re-enable it.
-
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.
