I am having a website (PHP/MySQL). Recently I upgraded the server and installed SSL certificate to my website (server).
Server and SSL details are
HTTP Server Header: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.5.29
Protocol (supported): TLS 1.2
Protocol (NOT supported): TLS 1.0, TLS 1.1, SSL 3, SSL 2
I am using Cdyne SMS Notify API in my website. Cdyne posts back (to a page I have specified in Cdyne call) after completing process at their end when I send request to them.
Without SSL (https) everything works good and I get back post backs (to a page I have specified in Cdyne call) from Cdyne but when I enable SSL (https) then I don't get posts back. I contacted with Cdyne support, they replied that they are getting following exception when they try to send reply (post back) to my website.
The request was aborted: Could not create SSL/TLS secure channel.
What can be the reason? And what can be the solution. Do I need to change my code or do they will have to alter their code. Any help is appreciated.
Last but not least, requests (SMS) from my website are successfully delivered with SSL (https). Means everything is good at my end? Issue is only with post backs from Cdyne.
Thanks in advance,
CDYNE recently performed a security upgrade. It also required a patch to our previous version.
This upgrade was to ensure that all of our customers, from legacy to current versions, have the highest level of encryption for their data. There was a minor interruption while this transition occurred and isn't a regular occurrence with our services.
If you experience any issues in the future, you can always chat with us online through our website or call our tech support line at 1-800-984-3710.
It was Cdyne's implementation which was not allowing posting back to TLS 1.2 server. After they fixed the code at their end everything is working fine.
Related
I am trying to set up webhooks for Stripe. The webhook connects to https://authdomain.subd.com which then forwards the request (after adding a validation token) to http://www.workdomain.com
Both these urls are hosted on the same server.
Payment Intents generated from http://www.workdomain.com successfully go into Stripe.
(Update: I can also query run successful Stripe commands like \Stripe\Charge::all() from authdomain, which verifies that TLS 1.2 supported)
However the webhook returns a TLS error when trying to connect to https://authdomain.subd.com.
I have whitelisted Stripe's IP as listed here enter link description here
This process is working fine when I test it locally using a CLI, so I know I don't have to install Stripe on my auth layer project.
But for some reason when I try this on my live server it doesn't work on my live server.
Is there any reason this is happening?
Thanks for the help
This can be caused by any number of things, but the most common is an incomplete certificate chain. I'd recommend using Qualys' SSL Labs tool to check your server's TLS configuration. For example, to check the domain you shared:
https://www.ssllabs.com/ssltest/analyze.html?d=https://authdomain.subd.com&hideResults=on
If any of the intermediate chain certificates are marked as "missing" in this report, it can cause Stripe to refuse to connect to your webhook (as Stripe can't tie your TLS certificate back to a known global CA). Usually the fix is to download any missing certificates (the tool tells you which one) and add them to your production TLS configuration / bundle. You may need the help of your hosting company to configure this.
To test your repair, re-run the SSL Labs check after deploying the new certificate bundle and see if it's now resolved. Beyond that, if the problems persist I'd recommend writing Stripe support!
So my script (IPN listeners, API calls, etc) was working fine but suddenly started throwing an error about being unable to verify the SSL certificate. This is my error (PHP CURL shown)
SSL connect error
Why did it stop working?
Last year, PCI-DSS 3.1 came out and there was a major change for all people processing credit cards. Specifically, there was a mandate that all processing had to be done on TLS 1.1 or later only. The original sunset date was June 30, 2016, but that was postponed to June 30, 2018
The Payment Card Industry Security Standards Council (PCI SSC) is extending the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher).
Now, while this reprieve gives you, the programmer, some room to breathe in regards to your front end, it still means that moving to TLS 1.1+ is not optional (in fact I would mover sooner if I were you) and that some intermediate card processing will start moving sooner than that. PayPal, as it turns out, is one of those moving in regards to its websites
TLS 1.2 Upgrade
The most secure protocol for sharing information on the web today is Transport Layer Security (TLS) version 1.2. PayPal is enabling support for TLS 1.2 for all secure connections and in 2016 will start requiring its use. You will need to verify that your environment supports TLS 1.2 and if necessary make appropriate updates. PayPal is updating its services to require TLS v1.2 for all HTTPS connections on June 17, 2016. After that date, all TLS v1.0 and TLS v1.1 API connections will be refused.
Now, in theory, your old script (provided you're not storing PayPal's public key) should operate just fine but Sandbox (which has already moved to this) communications are already starting to fail. What I've found is that, for a variety of reasons, some communication layers (notably CURL in PHP, a very common way to talk to PayPal) cannot negotiate properly with PayPal anymore. Thus, you get the cryptic error
SSL connect error
Thanks CURL. That was helpful... (not)
So how do we work around this? Well, if we tell CURL to only use TLS 1.2 your calls to PayPal should start working again without issues. If you're using PHP and CURL you can do it by adding this like (where $ch is your CURL handler)
curl_setopt($ch, CURLOPT_SSLVERSION, 6); // Force TLS 1.2
This change is perfectly safe to use with both Sandbox and Live calls to PayPal.
I've put together a site utilising the Stripe payment system.
Upon making a test payment over HTTPS, I get the error:
Stripe no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later.
I've made sure all my versions of software are up to date:
PHP Version: 7.0.7
cUrl Version: 7.47.1
SSL Version: OpenSSL/1.0.2h
I've also tested my site itself on https://www.ssllabs.com/ssltest/analyze.html to make sure TLS 1.2 is enabled and functional on the server.
The only thing I can think is if there is possibly an issue with the certificate bundle I have registered in php.ini (CURL curl.cainfo setting), but since Stripe source has a "ca-certificates.crt" already included I wasn't sure if I even needed to set an entry for curl.cainfo in my php.ini file.
Any advice would be massively appreciated. If there is any additional information I can provide that might help, just let me know.
EDIT: Currently using Stripe's PHP Framework v4.1.1 (Latest)
The SSL cert you mentioned is used by your server to respond to incoming requests. What this means is that if I visit your website, as a customer, my browser (Chrome) will try to talk to your server over TLS 1.2 by default as it uses the most secure protocol first. Your server is apparently able to answer requests over TLS 1.2.
The issue we have right now is that when your server contacts Stripe's servers it negotiates TLS 1.0 by default instead of TLS 1.2. Since Stripe is going to deprecate requests made with TLS < 1.2 this means your requests will start failing next year if you don't upgrade.
What I'd recommend here is to talk with your webhost about this so that they can help you look into your setup and ensure that you do support TLS 1.2 requests from your server to Stripe's. Additionally, you can follow the steps outlined at https://support.stripe.com/questions/how-do-i-upgrade-my-stripe-integration-from-tls-1-0-to-tls-1-2 to ensure that your code libraries also support TLS 1.2.
This could also be caused by an outdated version of Stripe's PHP library. They released version 3.19.0 on Friday July 29th which corrected a bug that affected some setups which might explain why you're getting this error even if your host supports TLS 1.2. You may also try updating the Stripe PHP library that you are using to the current version to see if that solves your issue.
Problem was with my local issuer certificate, turns out I was on the right track.
Had to set a default value in my php.ini file for curl_cainfo and that fixed it.
So my script (IPN listeners, API calls, etc) was working fine but suddenly started throwing an error about being unable to verify the SSL certificate. This is my error (PHP CURL shown)
SSL connect error
Why did it stop working?
Last year, PCI-DSS 3.1 came out and there was a major change for all people processing credit cards. Specifically, there was a mandate that all processing had to be done on TLS 1.1 or later only. The original sunset date was June 30, 2016, but that was postponed to June 30, 2018
The Payment Card Industry Security Standards Council (PCI SSC) is extending the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher).
Now, while this reprieve gives you, the programmer, some room to breathe in regards to your front end, it still means that moving to TLS 1.1+ is not optional (in fact I would mover sooner if I were you) and that some intermediate card processing will start moving sooner than that. PayPal, as it turns out, is one of those moving in regards to its websites
TLS 1.2 Upgrade
The most secure protocol for sharing information on the web today is Transport Layer Security (TLS) version 1.2. PayPal is enabling support for TLS 1.2 for all secure connections and in 2016 will start requiring its use. You will need to verify that your environment supports TLS 1.2 and if necessary make appropriate updates. PayPal is updating its services to require TLS v1.2 for all HTTPS connections on June 17, 2016. After that date, all TLS v1.0 and TLS v1.1 API connections will be refused.
Now, in theory, your old script (provided you're not storing PayPal's public key) should operate just fine but Sandbox (which has already moved to this) communications are already starting to fail. What I've found is that, for a variety of reasons, some communication layers (notably CURL in PHP, a very common way to talk to PayPal) cannot negotiate properly with PayPal anymore. Thus, you get the cryptic error
SSL connect error
Thanks CURL. That was helpful... (not)
So how do we work around this? Well, if we tell CURL to only use TLS 1.2 your calls to PayPal should start working again without issues. If you're using PHP and CURL you can do it by adding this like (where $ch is your CURL handler)
curl_setopt($ch, CURLOPT_SSLVERSION, 6); // Force TLS 1.2
This change is perfectly safe to use with both Sandbox and Live calls to PayPal.
The site that connect sandbox paypal works , until recently
it can connect will curl
but when it send the request at the second time
it show the error of
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
I have tried some reference online and set the SSL SHA-256 cert of it but it return same error. Other suggest switch to TLS at the curl connection but it may not perfered as there are many project I have handled.
Are there any suggestion to connect sandbox paypal with SSLv3? Thanks for helping.
You'll have to switch the cURL request to use TLS 1.2 in order to use the PayPal sandbox. I'm in the same boat, and there's no way around it, unfortunately. They just activated the change on the sandbox environment a few days ago.
https://devblog.paypal.com/upcoming-security-changes-notice/
I'll add some extra info on this since the first answer doesn't really cover all of the important points.
Paypal has started rolling out some upgrades, the sandbox now requires TLS 1.2 for all requests, and production systems will also require this from June 2016 onwards.
To support this you will need to:
Ensure your server has OpenSSL 1.0.1 or above (which is when TLS 1.2 support was added).
openssl version will show you your version number.
Once you meet that criteria, in your PHP code you can force the SSLVERSION to TLS 1.2 with the following command:
curl_setopt($curl, CURLOPT_SSLVERSION, 6);
Or if you want a less hacky solution, it is possible to have the correct SSL version kick in automatically during the handshake, where the client and server compare available ciphers to find a common protocol. You appear to be using PHP + curl, so you'll need PHP 5.5.19+ and curl 7.29+ for this to take place.
I have similar problem with error 14077410 and SSL3. I upgrade my PHP server from 5.4 to 7.0 and error disappear.