Does anyone else have trouble submitting transactions to the sandbox even though you have an A rating on SSL Labs? SSL Labs clearly shows that our server is using TLS 1.2 only, yet we cannot submit a transaction to the Authnet sandbox.
Thanks for the reply, Richard.
We use Coldfusion 11 on Windows 2012 and have no trouble with Authorizenet's current production environment. We have one client setup to point to the sandbox with a call to
The sandbox rejects all transaction. We do not get any replies, return codes nor return messages...just a default connection error from our system after it fails to connect.
SSLLabs.com gives us an A rating that you can see from https://www.ssllabs.com/ssltest/analyze.html?d=paperlesspto.keritech.net&latest
We are behind our data center's firewall but they can't seem to find anything wrong and keep telling me it should work.
Is there a way to troubleshoot to see from your end why continue to be rejected?
Yes, all of our transactions originate from keritech.net
Paperlesspto.com is just a marketing site and does not submit transactions.
Regarding the disablement of TLS 1.0/1.1:
* we are successful sending orders to the sandbox via https://test.authorize.net/gateway/transact.dll - I can see then the posted transaction in the sandbox gateway portal
* we were UNSUCCESSFUL sending orders to the production gateway https://secure.authorize.net/gateway/transact.dll - this is when you turned off 1.0 and 1.1 on Feb 8th
* we were UNSUCCESSFUL sending orders to the production gateway https://secure2.authorize.net/gateway/transact.dll - this is when you turned off 1.0 and 1.1 on Jan 30th
All transactions are coming from the same server and same application which uses IIS on Windows Server 2012.
Please have someone work with me on troubleshooting this immediately. It is now at a critical stage.
as far as i know i'm using tls1.2.
i'm using php, stream_socket_client to make my connection to
apitest.authorize.net:443 (path /xml/v1/request.api)
periodically i get 'connection refused' for a number of tries, then a successful response.
this morning it was fine.
then a few minutes ago i got a response after 151 tries to connect.
then instant responses.
then 3 tries and a successful response.
now it's rejecting again.
when i connect using fopen to https://howsmyssl.com i'm informed that i'm using tls 1.2.
Important to remember: An SSLLabs report is irrelevant when it comes to your server making a client connection to another web server. Remember, the only thing SSLLabs can tell you is what version of TLS is negotiated when their machine makes a connection to the HTTP server software running on your server machine. That’s not what is at issue here.
It’s good that you’re enforcing TLS 1.2 connections when other machines are making connections to your machine. That’s definitely necessary, and required to be compliant with PCI-DSS. But, you also have to be capable of connecting as TLS 1.2 when your machine is acting as a client connecting to a web server.
So, what is at issue is the version of TLS that your machine is able to negotiate when your machine is connecting as an HTTP client to the HTTP server software running on the Authorize.Net endpoint. Whether your machine is capable of negotiating a TLS 1.2 connection when acting as a client is completely dependent on things like your programming environment that your application was written in and its libraries, or the system libraries that your application is calling to make this client connection.
So, short answer: Ignore the SSLLabs report and instead focus on the differences you're seeing between howsmyssl.com and apitest.authorize.net, and the intermittent success at connecting to Authorize.Net.
A suggestion: Use openssl to directly hit the server and see what's happening, using something like
openssl s_client -connect apitest.authorize.net:443
See how the output differs on a connection to hosmyssl versus authorize.net. See what's different between successful authorize.net connections and unsuccessful ones. Experiment with other openssl options to force different modes and see if that makes any difference.