cancel
Showing results for 
Search instead for 
Did you mean: 

A on SSLLabs - Still Can't Connect To Sandbox

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.

kornysnaps
Contributor
7 REPLIES 7

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

RichardH
Administrator Administrator
Administrator

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?

Hi @kornysnaps

 

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

 

Thanks

 

 





Send feedback at developer_feedback@authorize.net

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

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

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.

 

help?

 

thanks,

 

Otis Maclay

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.