cancel
Showing results for 
Search instead for 
Did you mean: 

Sandbox issues: The underlying connection was closed: An unexpected error occurred on a send.

We're seeing this on a GetCustomerProfile call through the .NET SDK as of this morning. 

 

  "exceptionMessage": "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.",
    "exceptionType": "System.IO.IOException",
    "stackTrace": "   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)\r\n   at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)\r\n   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)\r\n   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)\r\n   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)\r\n   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)\r\n   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)\r\n   at System.Net.TlsStream.CallProcessAuthentication(Object state)\r\n   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)\r\n   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)\r\n   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)\r\n   at System.Net.ConnectStream.WriteHeaders(Boolean async)",

 

 

I just also updated my sdk version, to make sure it was not that. 

 

This was working previous to today without any flaws or issues.

 

Thanks,

 

Jarrod Henry

jarrodh
Member
1 ACCEPTED SOLUTION

Accepted Solutions

We disabled TLS 1.0 and 1.1 in Sandbox, per https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/TLS-1-1-and-1-0-Disabl... -- but the changes didn't finish propagating until this morning.

Could you please confirm that you are set up to handle TLS 1.2 connections, using the ciphers listed on the SSL Labs report for apitest.authorize.net:

https://www.ssllabs.com/ssltest/analyze.html?d=apitest.authorize.net

 

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

View solution in original post

Lilith
Administrator Administrator
Administrator
11 REPLIES 11

We disabled TLS 1.0 and 1.1 in Sandbox, per https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/TLS-1-1-and-1-0-Disabl... -- but the changes didn't finish propagating until this morning.

Could you please confirm that you are set up to handle TLS 1.2 connections, using the ciphers listed on the SSL Labs report for apitest.authorize.net:

https://www.ssllabs.com/ssltest/analyze.html?d=apitest.authorize.net

 

--
"Move fast and break things," out. "Move carefully and fix what you break," in.
Lilith
Administrator Administrator
Administrator

I'm digging deeper to make certain, but we are using the .NET SDK that authorize.net released earlier, wireshark is showing TLS1.2 connections, and our .NET service is written in .NET 4.5.2, which supports TLS.  The azure service we're on is a windows server image, which supports that cipher, as well as windows 10 supporting that cipher. 

 

 

There we go, that was it. 

 

Thanks!

 

Jarrod

 

 

Hello, Jarrod -

 

Would you mind explaining what it was, exactly, that fixed your issue? We're seeing the same thing and I'm curious what resolved your issue.

 

Thank you -

 

Gary

 

This is what appears to resolve my connectivity problem, in my code.

 

Updated the underlying .NET Framework to 4.6.1 (works with 4.5.2, as well) and prior to interacting with the AuthorizeNet service, I tell the ServicePointManager explicitly to use TLS 1.2:

 

// in code

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

 

I gathered from what I read that Framework 4.6.1 would use 1.2 by default, but my solution would not work until I explicitly called out TLS 1.2 prior to attempting connection. In 4.5.2, 1.2 is supported but you must config ServicePointManager to use this version over others.

This solved my issue, thank you kindly!

Perfect!!!  We are in the middle of testing a new application and it failed yesterday when I submitted a transaction.  Thankfully, I was able to track it back to a communication error when I got the error "Authentication failed because the remote party has closed the transport stream."  I then added the line of code noted above (my Application is .NET 4.5) and it set the default to TLS 1.2.

 

My next transaction went through without a hitch.

 

Thanks for the Solution!!

 

 

Thanks:). You saved my time alot

yeh, 

 

It saved my time too. I was tring to figuring out whats the hell is going on with my code. It took days, then I saw this solutions.

 

Thank you All............