On 2/28 Authorize.Net disabled TLS 1.0/1.1 and customers can no longer check out with this payment method. Can't believe that there is no update for relevant files for OC v1.5.x. - did I miss something? I tested my server with https://www.ssllabs.com/ssltest/ and it was compatible with TLS 1.2 so I'm guessing its a code problem.
Can anyone suggest a solution for this problem? Customers are getting this message:
CURL ERROR: 35::Cannot communicate securely with peer: no common encryption algorithm(s).
Thanks much
See this post: https://community.developer.authorize.n ... rue#M24145 noticing if this is a coding issue with Opencart.
The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.
Regards,
Straightlight
Programmer / Opencart Tester
Posting my SSL test in case this is a server issue - advice welcome
Code: Select all
Cipher Suites
# TLS 1.2 (server has no preference)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 2048 bits FS WEAK 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 112
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) WEAK 128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 2048 bits FS 128
TLS_RSA_WITH_SEED_CBC_SHA (0x96) WEAK 128
TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x9a) DH 2048 bits FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq. 15360 bits RSA) FS 128
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS 128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq. 15360 bits RSA) FS 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp521r1 (eq. 15360 bits RSA) FS 128
TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128
TLS_RSA_WITH_IDEA_CBC_SHA (0x7) WEAK 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp521r1 (eq. 15360 bits RSA) FS INSECURE 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) WEAK 256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 2048 bits FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. 15360 bits RSA) FS 256
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS 256
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) WEAK 256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq. 15360 bits RSA) FS 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp521r1 (eq. 15360 bits RSA) FS 256Contact your host for these infos.
The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.
Regards,
Straightlight
Programmer / Opencart Tester
This shouldn't require any actual changes to OpenCart code. What you need is for your server to default to TLS 1.2 for curl connections, which should then make any extension (including Authorize.net) use 1.2 for its connection. Contact your web host and ask them to make sure TLS 1.2 is the default connection for curl.
@johnathan - I have OC 1.5.4 installed on Windows 2008 SP2 (with TLS 1.1 and TLS 1.2 support installed) I have edited the registry and force the server to use TLS 1.2 and its verified in SSL Labs website. However I still get the handshake error with CURL saying SSLv3, etc..
How can we change in CURL to make the app use TLS 1.2, i've seen posts saying to edit the Authorize.Net AIM file (module) and make it specifically use TLS 1.2, but when I do that the shopping cart just hangs at please wait, when I try and process the test 4111 1111 1111 1111 visa.
Does the Authorize.NET AIM extension in OC 1.5.4 work with TLS 1.2?
How can we change in CURL to make the app use TLS 1.2, i've seen posts saying to edit the Authorize.Net AIM file (module) and make it specifically use TLS 1.2, but when I do that the shopping cart just hangs at please wait, when I try and process the test 4111 1111 1111 1111 visa.
Does the Authorize.NET AIM extension in OC 1.5.4 work with TLS 1.2?
You should contact your web host to do this. I'm not sure how to set the server to default to TLS 1.2 for curl, but they should know how to do it. (If they don't, find a new web host.)
If you want to try forcing the curl connection to use TLS 1.2, you can adding this in the /catalog/controller/payment/authorizenet_aim.php file:
------------------------------------------------------------------------------
AFTER:
curl_setopt($curl, CURLOPT_TIMEOUT, 10);
ADD:
curl_setopt($curl, CURLOPT_SSLVERSION, 6);
------------------------------------------------------------------------------
If you want to try forcing the curl connection to use TLS 1.2, you can adding this in the /catalog/controller/payment/authorizenet_aim.php file:
------------------------------------------------------------------------------
AFTER:
curl_setopt($curl, CURLOPT_TIMEOUT, 10);
ADD:
curl_setopt($curl, CURLOPT_SSLVERSION, 6);
------------------------------------------------------------------------------
I finally got around to fix this issue with TLSV1.2 and Authorize.net. There ate two separate changes that need to take place:
1. Server SSL protocol. You need to make sure that only TLSv1.2 is active. To do so first run this command to see which protocols are active
Then run this to make only v1.2 active
If you run the first command you should now see this: ssl-protocols: TLSv1.2
Restart your server
2. This has to do with Opencart and as suggested by Johnathan it will fix the CURL Error 35: curl unable to communicate securely with peer
Open /httpdocs/catalog/controller/payment/authorizenet_aim.php
add this line (around line 111)
just below this line
Now you should be good. Remember PayPal will enforce this about June 2018, so u better be done now.
thanks all -- a
1. Server SSL protocol. You need to make sure that only TLSv1.2 is active. To do so first run this command to see which protocols are active
Code: Select all
/usr/local/psa/bin/server_pref -s | grep ssl-protocolsThen run this to make only v1.2 active
Code: Select all
/usr/local/psa/bin/server_pref -u -ssl-protocols TLSv1.2Restart your server
2. This has to do with Opencart and as suggested by Johnathan it will fix the CURL Error 35: curl unable to communicate securely with peer
Open /httpdocs/catalog/controller/payment/authorizenet_aim.php
add this line (around line 111)
Code: Select all
curl_setopt($curl, CURLOPT_SSLVERSION, 6);Code: Select all
curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 10);thanks all -- a
Thanks for the documentation. It will certainly help people in the future. However, to specify that the SSH console may be needed to apply the command lines would be useful to know.
Any official documentation you could provide based on these validations that needs to be done for June 2018 from PayPal?Now you should be good. Remember PayPal will enforce this about June 2018, so u better be done now.
The most generated errors being found on Opencart forum originates from contributed programming. The increased post counters are caused by redundancies of the same solutions that were already provided prior.
Regards,
Straightlight
Programmer / Opencart Tester
I am running into the same problem with hostgator and paypal. The sandbox testing isnt going through. I am running OC 1.5.6.4. Host gator has tls 1.0, 1.1, 1.2. However I think they need to make 1.2 the default tls. for my shared server but there acting like they cant do that. Saying I should buy a dedicated server. I am wondering if i need to update any files in my website as to force a tls version. June 30th is the day they go live with the tls 1.2 only. Not sure what to do... Help please
For others that read this, see my response to midwestshades' other post here:
viewtopic.php?f=20&t=205053&p=726297#p726319
viewtopic.php?f=20&t=205053&p=726297#p726319
With Authorize.net payment removing TLS 1.0 and 1.1 from the server was not enough.
Had to add this line to controller/payment/authorizenet_aim.php
Recently upgraded to OC 3.0.2.0 and I had to make the same change to controller/extension/payment/authorizenet_aim.php
Otherwise your get an error! The curl_setopt($ch, CURLOPT_SSLVERSION, 6); is requesting TLS v 1.2
Why not try adding it in controller/extension/payment/pp_pro.php - around line 135.
Let me know if it works.
Had to add this line to controller/payment/authorizenet_aim.php
Code: Select all
curl_setopt($curl, CURLOPT_SSLVERSION, 6);Otherwise your get an error! The curl_setopt($ch, CURLOPT_SSLVERSION, 6); is requesting TLS v 1.2
Why not try adding it in controller/extension/payment/pp_pro.php - around line 135.
Let me know if it works.
If your web host properly turned off TLS 1.0 and 1.1 (and all SSL versions) then there's no other way for curl to connect than TLS 1.2. Most likely, your web host told you that 1.0 and 1.1 were turned off, but that didn't actually happening. Forcing the connection to TLS 1.2 is fine, but it's not the ideal solution (since anything else using curl that you don't specify the curl_setopt() for will use a less secure version.
Well, first it will be good for everyone to know that it can be "forced" because not everyone has full control their hosting environment. I don't know about other things using curl, but authorize.net gateway simply did not work, unless it was specified in the code.
I have full control of my hosting environment and running this command in SSH
returns this
Showing that I have successfully deactivated TLS 1.0 and 1.1
Before doing this, I had three versions of TLS, what's to say which one is the default? And what is to say if Authorize or PayPal are asking for the default version. I only know that the de facto behavior was not to ask for the highest version AND that even after deactivation of lower versions, it still wanted us to specify the SSL version in the code. Go figure.
With respect to pay-pal, currently it is working for me without any changes to the code (using PP Express Checkout), but I am not sure what will happen come June 30th. I would like to know if others tried this in sandbox mode.
I have full control of my hosting environment and running this command in SSH
Code: Select all
/usr/local/psa/bin/server_pref -s | grep ssl-protocolsCode: Select all
ssl-protocols: TLSv1.2Before doing this, I had three versions of TLS, what's to say which one is the default? And what is to say if Authorize or PayPal are asking for the default version. I only know that the de facto behavior was not to ask for the highest version AND that even after deactivation of lower versions, it still wanted us to specify the SSL version in the code. Go figure.
With respect to pay-pal, currently it is working for me without any changes to the code (using PP Express Checkout), but I am not sure what will happen come June 30th. I would like to know if others tried this in sandbox mode.
Who is online
Users browsing this forum: No registered users and 24 guests
