Opera 12.17 no longer works with https for me

[stng]

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]

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]

blackbird71 last edited by

There 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]

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]

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.

[rseiler]

rseiler last edited by

Now add thepiratebay.se to the list.

[A Former User]

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]

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]

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]

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]

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]

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]

stng last edited by

@ppnsteve

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

[Deleted User]

Deleted User last edited by

Yes, choose Firefox, Chrome, Vivaldi... if you don't want Opera Blink.

[rseiler]

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]

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]

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]

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]

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=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 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.