Only sometimes, since two days: CurlException: 60: SSL certificate problem - ssl

Sometimes this appears, sometime not. Its since two days in former good running apps.
CurlException: 60: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed thrown in
With a former Version of the php SDK, I disabled CURLOPT_SSL_VERIFYPEER generally besause that never works. But the last two versions, now its the newest, worked until yesterday.Shout I disable something again? Is it the same method in the actual SDK? Writing from home, can't look inside.
Is it a message from the cert coming with the sdk or are that problems with the cert of https on my server?

You shouldn't disable CURLOPT_SSL_VERIFYPEER because of the security implications. The PHP SDK usually contains the needed certificate, but in your case it seems to have problems.
The best way to solve it is:
Download the Facebook SSL certificate here
Put it somewhere accessible by PHP
Tell the Facebook PHP SDK to use it:
Facebook::$CURL_OPTS[CURLOPT_CAINFO] = '/path/to/fb_ca_chain_bundle.crt';

I just ran into this same error (coworkers didn't have it) and the solution was to download a new copy of the Facebook API SDK from https://github.com/facebook/facebook-php-sdk. Apparently my version (and the certificate) was outdated.

Related

How to disable 'Your connection is not private' screen in Chrome?

I'm working on automating a web application (F# and Canopy). Getting 'Your connection is not private' screen upon launching the website/ after providing login credentials. Tried a few workaround to have the same disabled, but none did the job. Please help.
The best approach here is not try to hide or cover up the problem, but to fix it properly so you don't have to. Solutions that involve hiding the issue are necessarily going to adversely affect your security.
Note the wording of the error code: ERR_CERT_AUTHORITY_INVALID. That tells us that the certificate for the site is signed by a non-standard or unknown certificate authority.
You mentioned localhost in your comment; you're not going to be able to get a certificate for that, but you could create a self-signed one, however, if you've enabled the localhost exemption and you're still getting the error, it suggests that you may not be using localhost after all.
So, if you have a certificate signed by a real CA and you're seeing this error, it's likely that your local OS or browser has an outdated CA root certificate bundle. you can usually get the latest one by making sure your OS packages are up to date.
If your certificate is self-signed, then the 'advanced' button will allow you to add an exemption. I you have set up your own CA and signed the certificate with that, you need to add that CA's public key that signed it to your OS.
If you've got a "regular" commercial certificate from verisign, letsencrypt, comodo or whoever, then a run through a testing tool like testssl.sh or Qualys SSL labs will tell you more about what's going wrong. Without knowing the actual domain we can't test anything for you.
Added the following argument and it did the job:
options.AddArguments("--ignore-certificate-errors")

SSL error on Magento 2 Sign In for marketplace

I am posting this question on SO instead of ServerFault, because all my previous efforts to get Magento 2 issues sorted out, ended up being hacking some or other code in the Magento or template source.
I have configured a basic install of Magento 2 with a theme for a client.
Magento is running on IIS and Windows. (Not WAMP), shared IIS hosting on windows (My own server).
I configured the shop to use SSL, and the complete shop runs over SSL without any issues.
However, when trying to use the market place, I get a weird SSL issue:
"SSL certificate problem: unable to get local issuer certificate"
This error is shown on the Magneto shop (which is currently running over ssl), when trying to sign in to the market place.
I have found lots of hits on this issue, but all answers seem to lead to a self-signed certificate that isn't trusted or adding intermediary and/or root certificates. This is all based on XAMP, WAMP or native 'nix installations.
I do not understand what the exact issue is. I also do not know how to troubleshoot this further as the error description is very vague.
I would appreciate some feedback.
Thanks
This error happens because cURL cannot find a cacert.pem file from which take the trusted signatures.
There are some ways to set this file in cURL:
• Pass the cacert.pem file path directly to cURL when making the call;
• Set the path to the cacert.pem file in the php.ini.
You could follow below post:
• https://serverfault.com/questions/633644/adding-a-self-signed-cert-to-the-trusted-certs-within-curl-in-windows
• https://magento.stackexchange.com/questions/97036/magento-component-manager-ssl-certificate-problem-unable-to-get-local-issuer-c
• https://mage2.pro/t/topic/988
Regards,
Jalpa.

Bootstrap Certificate Problems in IE 8/IE 9

We are having problems with some browsers attempting to get Bootstrap 3 (js and css) from the documented CDN (https://maxcdn.bootstrapcdn.com/bootstrap/3.2.0/js/bootstrap.min.js). The main two browsers are IE8 and IE9 and we don't have option of telling client to upgrade. Other high level browsers (even IE11) seem to work properly.
We've had to resort to hosting files ourselves, but obviously I would much rather reference the CDN.
For a simple example, in IE11, if I do the following:
1) Type following in url...
2) Hit enter...
3) Click Run...
Now, IE11 will actually continue and run (obviously script will error out), but all these warnings are my best guess as to what might be tripping up IE8/9 (and maybe other lower level browsers). As I said, I've temporarily hosted the files on our own secure.benefittech.com domain, and no warnings occur when I do same steps.
Here are some screen shots from client browser (IE8) when attempting to run the real site referencing CDN urls.
This first one is showing the debugger not knowing what the .tooltip() method is (from Bootstrap.min.js).
Finally, this is the IE security bar warning they get when hitting the site
Any ideas on how this might be resolved or what info I could supply MaxCDN with to try and resolve this would be greatly appreciated - or do we have to continue to host files ourselves?
I realize IE8/9 are old browsers (neither of which I'd be running at this time), but as mentioned earlier, I don't have option to force client to upgrade and surprised no one else has raised this issue (when I contacted MaxCDN, they were surprised by the issue, but not being experienced in Certificate 'technology/language', I didn't really know what to provide them.
Do you have a test environment with IE8/9 where you could do some tests? It could be a problem with certificate chain building. Maybe some certs in the chain are not trusted.
Could you import SubCA certificate from http://secure.globalsign.com/cacert/gsdomainvalsha2g2r1.crt to intermediate CA store and Root CA from http://secure.globalsign.net/cacert/Root-R1.crt?
SubCA certificate (GlobalSign Domain Validation CA - SHA256 - G2) is pretty new (issued 20.02.2014) so if IE8/9 does not follow authority info access from end entity certificate (to build certificate chain) or it does not handle well that the certificate of subCA is in PEM format at http://secure.globalsign.com/cacert/gsdomainvalsha2g2r1.crt (should be DER IMO) or if by any chance GlobalSign Root CA is not trusted by IE8/9 then I believe this could be the reason for the IE warnings.

OpenSSL error when authenticating user for DocusignAPI

We are trying to use composite templates (fillable PDFs) and embedded signing using the REST API. We are using the docusign_rest gem in conjuction with our custom code to create composite templates and embedded signing. The docusign_rest gem is used for authentication and is giving the following error:
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)
On the local dev machine, we simply provided path to a certificate file at the time of starting the dev server, but on a remote machine this is not feasible.
Is it possible to skip the SSL check for a demo purpose? This SO link seems to suggest that it is possible. If yes, then how can we achieve that?
If not, then is there a quick way to fix it or do we have to install SSL certificates and configure the server to read those?
We are using ruby 1.9.3 , rails 3.2.11 and Apache2 (so that would mean enabling the SSL module).
I believe for demo (demo.docusign.net) you can use https OR http. What happens if you simply use http? Does that resolve your SSL error?
In either case, you'll eventually need to resolve this though because for production (www.docusign.net) you need to use https. The problem is most likely in your Ruby code or with your certificate. For testing purposes I'd try making a cURL request through the command line to see if that works.
See here for some examples of making DocuSign REST API calls using cURL

Heroku Bad response from SSL Endpoint provider

Good morning,
I am attempting to update my SSL certificate on Heroku but keep on getting a error:
! Bad response from SSL Endpoint provider. Please try again later.
I have gone though the steps to create a bundle multiple times with no luck. From what I can tell this can mean there is an issue with my certificate or that there is an issue with Herokus services. There is mention of the SSL Doctor tool provided by Heroku, but the Github repo says to use the Toolkit but I have not been able to find any documentation on what the command is or how to use it.
I thought about removing my current SSL key but I have been at this for weeks and I don't want SSL to be down for that long.
Anyone experience this before, or know how to use SSL Doctor (or if SSL Doctor will even help).
Thanks in advance!
I ran into the same problem. It turns out - I was using the Heroku gem to handle the operations. All I had to do was uninstall the Heroku gem, and then install the latest toolbelt from Heroku. The worst part about this problem was that it failed silently. :(