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!

[zigerati]

Our Sandbox tests worked and now our system is not working after the rollout. No good direction from Authorize.net. We're confirmed with our Datacenter, Rackspace, that the server configurations are correct. Basically we're getting a "Status call failed" related to our recurring billing and connection errors for standard purchases. We've removed all weak cyphers and the servers are confirmed TLS 1.2 only. We're desperate. Any ideas? 

[kvsunil]

As posted in one of my replies above, even after configuring Unlimited JCE support JDK 1.7 didn't fix the issue!!!

Surprisingly, "The same solutions" are working with sandbox.

Dear Authorize.net Support, Your Sandbox and Production are supposed to be in same configurations. But it is not yet. What else needs to be done? Something missing.

[kvsunil]

Since no use testing against Authorize.net Sandbox with JDK 1.7 went ahead and tested against Authorize.net production with JDK 1.8. That solved the issue!!!

Now need to setup and test with dev servers and then to production.

Authorize.net, any information from your end? Authorize.net Sandbox works with JDK 1.7 but not Production?!? What is the production readiness?

[kornysnaps]

We had the same issues with the sandbox vs production and received no help from this service.  Fortunately we have been planning to move away from authorizenet and were force to speed this up in the past two weeks.  We now have 99% of our clients using another gateway.  The 1% that remain do now seem to work in production.  My only guess is because we upgraded from java 1.7 to java 1.8 this past Saturday.

It is a comfort to know that we have cleared this hurdle, but the bad taste lingers. The 1% will remain with authorize because they are lower volume, but we have no intention of coming back with the 99% that have been moved away.

I probably lost 10 years of my life because of this ordeal.  

[weyco44]

We had a contingency plan to jump ship, similar to what kornysnaps described.  This shouldn't be neccessary, but the fear of coming to work and having all eCommerce grind to a halt will put some gray hairs on a head rather quick.  It was all ready- could have been done at 2:01AM and we would be a lost customer.  There are other payment provider options out there.  Authorize.net isn't the only game in town.

To anyone still struggling a suggestion would be to reorder cipher suites.  If authorize.net wants to use SHA2 or SHA3 consider putting them at the top of the order.  You may not want to leave out any of pre-existing ciphers as, if you are like us, authorize.net isn't the only gateway to talk to.

[LoginId5678]

This TSL1.2 upgrade has been bungled by authorize.net. 

It turns out that production is different from the configuration deployed in their staging/test which everybody used to validate 1.2 compatibility!!!

Secondly, even now there is a difference in the TLS / Cipher between their akami production URL (https://api2.authorize.net/xml/v1/request.api) and the non-akami URL (https://api.authorize.net/xml/v1/request.api). With JDK1.7, we are able to hit staging and akami prod URL, but the very same codebase results in a SSLHandshake exception when targeting the non-akami URL.

Per their docs, both endpoints are valid, but it is highly unprofessional that they have different ciphers or configuration.