Empty Response from secure2.authorize.net and test.authorize.net

[richardrega]

I recently started the transition to https://secure2.authorize.net/gateway/transact.dll

The newer functions in the system that use https://github.com/AuthorizeNet/sdk-java are just fine, but the much more important and common scripts based on something called the "JCommerceSQL Authorize.net Gateway" do not work with these new Akamai URLs.

I can step through and see my SSLSocket startHandshake(), I write to the OutputStream(), but when I getInputStream() the read() is just empty. Nothing. No errors, no exceptions, nadda.

I can take all the parameters and put them into a web browser and POST everything that way, so I know the account is just fine.

I don't know that much about this old JCommerceSQL thing, but it looks like the header is HTTP 1.0 and TLSv1? I don't know if that matters, but it looks like this migration to Akamai will involve more than a simple URL update.

[RichardH]

Hello @richardrega

A quick check of SourceForge shows that JCommerceSQL hasn't been updated since 2007.  

Richard

[richardrega]

Hello @RichardH

I know the Authorize.Net library we're using is very very old, but management is under the impression that we shouldn't have to spend much time updating our system to use the Akamai Server's new URL.

According to all the FAQs, the transition is simple.  It looks bad when I can't get it to work.  They can read these forum posts.

I need a better technical reason other than "our library is too old and Authorize.Net lied" to justify rewriting software that has been solid for years.

If there really is some hidden technical problem, we have to go through another cost benefit analysis and think about why we're still using Authorize.Net at all...

[RichardH]

Hello @richardrega

I can appreaciate the challenge you are facing.  If you are able to connect via a modern browser, but your Java-based application is not able to connect through Akamai, the problem may be with your version of Java not supporting the new SHA-2 based certificates.

Are you testing this in the sandbox which is configured with Akamai, or using the new production URLs?

We encourage merchants and developers to keep their platforms, frameworks and systems up to date to ensure they support the latest security updates to maintain PCI Compliance.

Richard

[richardrega]

OK, I can see stuff like:

TLSv1, CipherSuite$MacAlg "SHA", "HmacSHA1", "SHA1 Message Digest from SUN"

inside the dugger when connecting, so the older library is clearly not using SHA-2.

The older library is not regularly tested on the Authorize.Net sandbox.  As a part of this investigation I tried to connect to "test.authorize.net", "secure2.authorize.net", and "secure.authorize.net".

Only "secure.authorize.net" works.

An Authorize.Net support person recently emailed me a link to this relevant blog post:

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Production-Certificate-...

It looks like Authorize.Net added SHA-2 support a while back while still accepting SHA-1 connections.

If Akamai isn't supporting SHA-1, that would explain my problem.

~Thanks