C# SslStream.AuthenticateAsServer() intermittently blocks indefinitely. Recovers after restart of application. RRS feed

  • Question

  • Hi,

    I have a socket server and client application using SSL running on a private network with domain controller, certificate authority. It just ran fine for months and suddenly I face a problem while calling SslStream.AuthenticateAsServer() and it gets blocked indefinitely. This is making my application not to call BeginAccept() to further accept client connections resulting in Connection Refused on client side. Investigated everything but clueless why AuthenticateAsServer() hangs... The issue observed on production environment.

    Server app runs on Win Server 2008 R2, Client runs on Win 2003 Server. Both apps in C# 3.5

    I have the following questions:

    1) A network glitch causing server app hang while authenticating clients?

    2) Any Dns/CA related errors can cause this issue?

    3) Server app unable to fetch certificates causing the API call hang?

    4) One of the client connections having incorrect certificates (like without private key) causing the issue? The server uses the ceritifcate with private key.

    5) Able to reproduce with telnet command to the IP and port and leaving the window open. The telnet connection used is not secured and this is what causing the problem?

    6) No Read and write timeouts set explicitly. So its taking default infinite timeout which is the cause? If yes, but why it has to wait that much? 

    Any suggestion or clue what might be going wrong is very helpful. Thanks in advance.



    Tuesday, March 5, 2013 6:20 PM

All replies

  • Check to see if the port number is open using "netstat -a" in a cmd.exe window

    Check Task Manager to see if the process is still running

    Check Control Panel - Administrative Tools - Services  to see if the service is started.


    Tuesday, March 5, 2013 6:47 PM
  • The port is listening and the process and windows service are running. When the problem happens, it'll continue to serve already connected clients but stops accepting any new connections. When the problem is seen, telnet to the IP, port says "Connect Failed" if  done on the same server as socketserver is running or on any other server in the domain.


    Tuesday, March 5, 2013 6:55 PM
  • Hi,

    Are you getting any exception? If So please post the exception. If you are not getting any exception and it just hangs, please take server traces and post the stack trace


    Tuesday, March 12, 2013 10:08 PM
  • Hi,

    I have the same problem.

    I do AuthenticateAsServer on server side and AuthenticateAsClient on client side.

    Sometimes (not reproducible) they both hang. No exception, just hang. When I run the programs under debugger, debugger says that both hung at winsock recv; so both expect each other to give them something.

    The question is: what do they wait for?

    I would be glad to have any trace if it is possible.

    So, another related question is: how to produce some trace to get some picture of what is happening within SslStream objects?

    This hang is not reproducible. When I try to cause it intentionally - connect and disconnect from my server 10 times in a row, for example, - it works as expected.

    Thursday, October 15, 2015 12:52 PM
  • The issue reproduces pretty often. Although it can't be reproduced intentionally, it was reproduced today twice.

    Thursday, October 29, 2015 3:09 PM
  • This is late but may help somebody in the future: you need to set a ReceiveTimeout on the underlying socket to prevent this call from blocking forever.

    My best guess is that this blocks when the client drops out right after connecting, or if the thread accepting the connection takes so long (maybe because the server is so busy) that when it finally tries to accept the connection, the client has timed out and is no longer there. In other words, the half-open connection problem.

    Additionally, be aware of the following odd behavior in the socket Begin* methods: contrary to the normal expectation, the callback passed to them may actually execute synchronously on the thread that called the Begin* method, e.g., see the remarks on BeginAccept.

    What this means is that, if .NET decides to accept a connection synchronously on your listening thread, and the authenticate call (or any other call) blocks forever, then your listening thread will be blocked forever! To fix this, make sure to check the IAsyncResult.CompletedSynchronously property when your callback executes, and if it is true, turn around and manually call your callback on another thread, so that your listening thread remains free to listen. Hope this helps.
    Monday, April 24, 2017 4:35 PM