11-27-2017 12:09 PM
Mike - use the URL I previously posted for SSLLabs to see what version TLS your server supports, and then post back here what you find. Yes, it may not be a TLS version issue but all I did was port my website from old TLS 1.0 webserver to new TLS 1.2 webserver and I've not processed about 30 transactions with ZERO failures! I had 30% failure rate before the move.
Also, please configure a Wireshark box (or similiar) to capture all traffic between your server and Authorize.Net servers. Best if you can do it on the exterior side of your firewall, but even inside is better than nothing. Then when a failure happens check the trace and see if a Authorize.Net server attempted to contact your server, and give them that info and ask them to prove it's not their problem by providing Wireshark traces showing them communicating with your server. It will clearly show the problem (unless the communication never made it outside their server).
There is lots of good info in this forum thread, especially what RichardH says! There are multiple Authorize.Net customers seeing this problem. They keep telling me "you know that TLS 1.0 won't be supported after February 28, 2018, and we recommend moving to one of our newer APIs".
Authorize.Net could very quickly and easily prove to you (and everyone else) that it's not their problem by collecting Wireshark traces showing how communication with our servers had errors. In my case they say "here are the WinInet Error numbers our server is reporting: 12156, 12175, 122". After analyzing those errors I posted back to them why each one showed the problem was on their end! Still no follow up on their part after I informed them of my findings.
11-27-2017 01:28 PM
You probably will, had several this morning.......
No failures and lots of transactions posted...I'm guessing they have a server that is only allowing TLS 1.2 and we are/were occasionally hitting it.
I though the TLS change was going to be major but it only took me a few minutes to change on Server 2008.
11-27-2017 01:54 PM
BenPutnam - your guess matches mine, that one of the Authorize.Net servers only allows TLS 1.2. Hence why I've been saying to not waste your time migrating to a new API, and either upgrade your server so that it supports TLS 1.2 or do as I did and migrate to a server that already supports TLS 1.2.
11-27-2017 03:40 PM
The ironic part is that if AUTHORIZE.NET HAD ACKNOWLEDGED THE ISSUE 3 WEEKS AGO, I would have had a major server upgrade done by the 18th or sooner. Instead, I've spent umteen hours (including several while I was on vacation) trying to chase this down because it is 'our fault', as well as time spent fixing the data that got screwed up by this.
There was no sense adding another server to a broken network so we backburnered the server, which would have apparently fixed the problem - IF WE KNEW THAT THEN!
How difficult would it have been to issue a statement like "we had to put a new server online that only accepts TLS 1.2, so upgrade now"?
The IT world needs to move away from the "not our fault" answer typical of 20 years ago and just start being truthful. I might have grumbled but I wouldn't have spent weeks chasing my tail.
11-27-2017 06:34 PM
I too have been facing this issue and despite contacting them through ticket# 1-468855651, no response as yet.
But I am not sure if the TLS issue will resolve this since we are using SIM and the https layer of the relay response should have nothing to do with this, even if using SSL:
"I use Simple Checkout, so are there any changes I need to make? No changes are needed, other than ensuring that your customers are using modern/up-to-date browsers to avoid any errors or issues after February 28, 2018."
MikeCO, after doing this upgrade, was this issue resolved for you? If so, could you tell me know if you are using SIM or AIM?
11-28-2017 06:46 AM
The problem is the response relay needs to 'speak' to your server over a secure channel, so your server apparently needs to support TLS 1.2, by February 28th, 2018, or November 3rd, 2017, lol.
Our Linux server has a lot of dependencies and just compiling a TLS mod and installing it is risky that it could blow something else up. We are going to try and fire up the new server later today, at least in a role of webserver. I'll keep you posted...
11-28-2017 08:59 AM
I created an intermediate app on a server with TLS 1.2 to relay any post's coming back from Auth.net to my app that can only use TLS 1.0. I have had exactly 0 errored transactions since I did this 8 days ago.
I asked the call center no less than 3 times if the TLS upgrades could be causing this issue and the furisouly denided it. Seems like somebody needs dig deeper on Auth.net's end.
Seems like the solution is to upgrade your host server to have TLS 1.2 as the primary cipher
11-28-2017 09:08 AM
It sounds like it is worth trying. I can easily stand up a new server and point the Authorize relay reposnses to it ...
So I am not a security expert ... what is involved in upgrading from 1.0 to 1.2? Any good technical references?
11-28-2017 09:27 AM
Yet another confirmation that the issue is a TLS 1.2 issue! If we get one more confirmation I suggest we, the customers of Authorize.Net, mark this issue as solved.
sboyle - how to upgrade your hosting platform to TLS 1.2 will depend on what your hosting platform is. If you are on 'Server 2008' BenPutnam posted some info for it above here.