- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ02-06-2018 05:14 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
โ02-06-2018 03:09 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
โ02-06-2018 03:18 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
โ02-06-2018 11:47 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
paperlesspto.com's security certificate is from keritech.net which only covers *.keritech.net.
Certified Authorize.net developers
โ02-09-2018 02:17 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ02-09-2018 03:29 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
โ02-12-2018 11:08 AM - edited โ02-12-2018 11:10 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ02-14-2018 09:50 AM