TLS 1.2 Sandbox vs Production

[kvsunil]

We have tested our sandbox instance after explicitly enabling JDK 1.7 to support TLS 1.2 . This worked fine without issues. So we have applied the same for production server. While checking on our production during the temporary TLS 1.2 enablement on Authorize.net production,   it is running into the following issue : “javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure”

Sandbox Url : https://test.authorize.net/gateway/transact.dll

Production Url : https://secure.authorize.net/gateway/transact.dll

It seems like there is something different between Authorize.net Sandbox vs Production. Please advise. Thank you!

[jantzenw]

We ran into a similar problem. Here is a partial list of ciphers that work on beta but did not work during the live disablement testing yesterday: 

ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:KRB5-IDEA-CBC-SHA:KRB5-IDEA-CBC-MD5:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-KRB5-RC4-MD5

It seems like beta is accepting DEFAULT:!TLSv1.0 but live was allowing only DEFAULT:!TLSv1.0:!SSLv3

[kvsunil]

Could someone please advise what actually needs to be setup for JDK 1.7? The settings applied on Sandbox instance works fine as explained above. Whereas the same failed on production during the temporary disablement on February 8th. Please advise.

Thanks in advance!

[weyco44]

We ran into the same issue.  We even tested the sandbox during the disablement period, just to verify that we had things running  on the sandbox environment. 
correctly

We were led to believe that the sandbox would mimic the production environment, following the permanent disablement of the TLS 1.0/1.1.

Is there anyone that has found the differences between the sanbox and the temporarily disabled production site? 

We have a ticket open, have done online chats, and had phone calls with no luck so far.  Any help would be greatly appreciated.

[kvsunil]

It seems like mostly this issue is because of JDK 1.7 JCE Unlimited Strength was not enabled.

Enabled JCE Unlimited Strength for JDK 1.7 on dev instance and tested against Authorize.net sandbox. It worked as usual even without this.

Enabled the same (JCE Unlimited Strength) on production and waiting Fingers Crossed. Need to check how it goes on Feb 28th! If that works Authorize.net sandbox and production are not on same security base line.

Ref: https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https 

"Example of diagnosing a problem" section.

"In the case above, the failure occurred during the handshake. The most likely cause for that is algorithm support. The JDK provides a separate package called JCE Unlimited Strength, designed to add stronger algorithm support than what’s available by default."

"Adding stronger algorithms: JCE Unlimited Strength" section:

In a high security environment, one way of strengthening algorithms in the JDK is through the JCE Unlimited Strength policy files. In this particular case, replacing those policy files within JDK 7 allows it to use the stronger variants of existing algorithms and connect successfully.

Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7 Download :

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html 

Thanks!

[kornysnaps]

Authorizenet's production and snadobx envirnments are clearly different from each other.

We use the same server to test both and the sandbox works but production does not.  On Jan 30 we tested successfully against the sandbox, then two minutes later failed against production using  Akamai.  On Feb 8th we tried the same thing with the non-Akamai gateway and had the same results.

Since Feb 8th I have been trying to get help from Authorizenet.  Yesterday the first reply came saying we were using TLS 1.2 on 1/30 and 2/8.   HELOOOOO!  We know that.  They did not go any futher to look into production versus sandbox.

We have used this service for the past 15 yesrs and have never had good support.  It is like they are in another universe.   

We now have less than 5 days before they turn it off.  Obviously they do not care.  It is probably more like they are not capable.

[raviparmarce88]

We have forcefully override tls1.2 version in our application and it is working fine in sandbox without any issue.

We hope it should also work in production.

[Anurag]

Hi All , 

We have updated our FAQs for the cipher support 

https://support.authorize.net/authkb/index?page=content&id=A1623&actp=search&viewlocale=en_US&search...

For cipher support ECDHE and AESGCM are preferred, SHA-1 ciphers will be not be supported. For a full list/report SSL Labs report can be run to see and verify TLS version and ciphers supported. Please see below for a matrix of reports available, by API endpoint and environment.

	Production	Sandbox
Transact, Legacy (Non-Akamai)	https://www.ssllabs.com/ssltest/analyze.html?d=secure.authorize.net	Not Applicable
Transact, Akamai	https://www.ssllabs.com/ssltest/analyze.html?d=secure2.authorize.net	https://www.ssllabs.com/ssltest/analyze.html?d=test.authorize.net
ANet API, Legacy (Non-Akamai)	https://www.ssllabs.com/ssltest/analyze.html?d=api.authorize.net	Not Applicable
ANet API, Akamai	https://www.ssllabs.com/ssltest/analyze.html?d=api2.authorize.net	https://www.ssllabs.com/ssltest/analyze.html?d=apitest.authorize.net

[raviparmarce88]

Hi 

Could you please let me know how can we ensure that current production version would work fine after this tls disablement ?

Current application with Sandbox is working fine.

[weyco44]

Has the sandbox been updated to reflect this?  Was this how the production version was set up during the Feb 8th test?  Was there a mistake made while doing the test run that caused all of these errors for people?

Is there any way to verify that we will not lose connection once the Feb. 28th deadline comes?

Why did it take this long to give any sort of response?