topic Re: A on SSLLabs - Still Can't Connect To Sandbox in Integration and Testing

A on SSLLabs - Still Can't Connect To Sandbox

kornysnaps — Tue, 06 Feb 2018 13:14:25 GMT

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.

Re: A on SSLLabs - Still Can't Connect To Sandbox

RichardH — Tue, 06 Feb 2018 23:09:39 GMT

Hello @kornysnaps

Can you tell us a bit more about how you're connecting to our Sandbox? For example, are you using one of our SDKs or hitting our endpoint directly? Which platform are you using?

Richard

Re: A on SSLLabs - Still Can't Connect To Sandbox

kornysnaps — Tue, 06 Feb 2018 23:18:14 GMT

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

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

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?

Re: A on SSLLabs - Still Can't Connect To Sandbox

Anurag — Wed, 07 Feb 2018 07:47:29 GMT

Hi @kornysnaps

Can you reach out to our CS team on 1.877.447.3938 for more details ?

Thanks

Re: A on SSLLabs - Still Can't Connect To Sandbox

NexusSoftware — Fri, 09 Feb 2018 22:17:58 GMT

paperlesspto.com's security certificate is from keritech.net which only covers *.keritech.net.

Re: A on SSLLabs - Still Can't Connect To Sandbox

kornysnaps — Fri, 09 Feb 2018 23:29:52 GMT

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.

Re: A on SSLLabs - Still Can't Connect To Sandbox

omaclay — Mon, 12 Feb 2018 19:10:41 GMT

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.

help?

thanks,

Otis Maclay

Re: A on SSLLabs - Still Can't Connect To Sandbox

Aaron_Actual — Wed, 14 Feb 2018 17:50:57 GMT

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.