SSL错误无法更改为TLS

Question

I have been working for quite some time on a website that highly depends on Paypal working properly on it. Without it, it is really useless.

Around 1 in the morning my time (I am at CET timezone) everything working perfectly, I polished up the code, functions and it was working as it should. I made triple checks before I went to sleep that everything works as it should.

I wake up in the morning and nothing that has to do with Paypal actually works. A little bit of an explanation of what I am using before I show you the actual code and error. I am using Express Checkout and Paypal Adaptive Payments SDK .

I have a few "virtual" accounts that I made on developer.paypal.com in order to simulate facilitator (owner) and buyer interaction since I have scenario when owner gives money to ther user and visa versa. Anyhow they both worked perfectly and now they both throw this error (in Adaptive Payments SDK, it tells me in which line of code is a mistake and in Express Checkout since that is code that is done via documentation it does not show in which file the error is but it is the same error):

'error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure'

Now after I saw this post https://devblog.paypal.com/poodle-ssl-3-0-vulnerability/ that you just disabled SSL totally, I realized that the problem is in that actually. You want your users to use TLS now which is totally fine. I triple checked that my server has TLS enabled and it does and I changed (for over a million times already) my config settings to use that TLS in cURL (since I am using PHP) by doing something like:

curl_setopt($ch, CURLOPT_SSLVERSION, 1); (this is how it looks like in Express Checkout and in Adaptive Payments it is just an associative array , but it is really the same thing in both)

I also found somewhere and in your advices to actually update my api credentials. I did that. I went to paypal.com -> API and then clicked update which worked, but then I noticed that on my developer.paypal.com account where I have a few of virtual accounts nothing has changed. Should I update those manually or what?

Edit:

This was sent to Paypal support and I was really in a hurry and could not write the entire thing again, so sorry about that! Issue is fixed thanks to anyone who actually took time to read it.

The issue was fixed with the adding CURLOPT_SSL_CIPHER_LIST => 'TLSv1' to my PPHttpConfig.php file! :)

Answer 1

Try add

CURLOPT_SSL_CIPHER_LIST => 'TLSv1'

to your PPHttpConfig.php file. I had the same issue with you and spent hours to find the solution. This worked for me.

Answer 2

One of the reasons for this error is older version of PHP and OPENSSL for eg PHP 5.3.5 will cause this error.

Solution, update the PHP (recomended >= 7).

Answer 3

This comes up when searching for Magento Error:14077410:SSL Routines:SSL23_GET_SERVER_HELLO:sslv3 Alert Handshake Failure! If you are trying to solve that, here is the link to the guy who originally solved the issue along with a downloadable patch: https://www.dwdonline.com/blog/fix-magento-error14077410ssl-routinesssl23_get_server_hellosslv3-alert-handshake-failure.html It's the same error - just in another software package.

Answer 4

I've had the same problem.

My server is an old version of Ubuntu 12.04

1. Check sertificates echo "All certificates in ca-certificates.crt, listed by subject, check for presence of VeriSign's 'Class 3 Public Primary - G5':" awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep "G5" echo "All certificates in ca-certificates.crt, listed by subject, check for presence of VeriSign's 'Class 3 Public Primary - G5':" awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep "G5"

2. I updated openssl.

   sudo apt-get install openssl

3. I could updated curl only by this instruction. http://pavelpolyakov.com/2014/11/17/updating-php-curl-on-ubuntu/ curl 7.47.1 version

4. And I updated libcurl. http://juniway.blogspot.com/2015/12/curl-48-unknown-option-was-passed-in-to.html