Authenticate as SSL client failed. You might be connecting to non SSL port.

Question

Hello Support team,

We are getting the error "Authenticate as SSL client failed. You might be connecting to non SSL port." if we try to connect to a mailserver using POP3 SSL. We have tried the application on three workstations, on two of them it works and on one it doesn't. We also tried to connect to the mailserver using an OpenSSL connection and this works on all three of the workstations.

I hope you guys can help us. Below the full error;

Unhandled Exception: Limilabs.Client.ServerException: Authenticate as SSL clientfailed. You might be connecting to non SSL port.
---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size,SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocol Request asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, syncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509
CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)
at Limilabs.Client.ClientBase.☻(Stream ☻)
--- End of inner exception stack trace ---
at Limilabs.Client.ClientBase.☻(Stream ☻)
at Limilabs.Client.ClientBase.♣()
at Limilabs.Client.ClientBase.Connect(String host, Int32 port, Boolean useSSL)
at Limilabs.Client.ClientBase.ConnectSSL(String host, Int32 port)
at mailtest4.Program.Main(String[] args)

Answer 1

The error indicates that server closed the connection:

An existing connection was forcibly closed by the remote host.

How is this one machine different from all others?

What happens if you only allow TLS 1.2:

client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Tls12;
client.ConnectSSL("mail.example.com");

What happens if you only allow SSL 3.0:

client.SSLConfiguration.EnabledSslProtocols = SslProtocols.Ssl3;
client.ConnectSSL("mail.example.com");

Comments

Thank you for your answer, the 2 workstations that work are Windows 7 machines, the workstation that doesn't work is a Windows server 2012 machine. The strange thing is that it does work with OpenSSL, does the mail.dll acquire additional software/rights?

We will change the code and try it again with TLS 1.2 and SSL 3.0.

---

Mail.dll needs .NET framework only. All security features (like SSL/TLS) are provided by the .NET framework and the OS.

---

We changed the code to SSL 3.0 and TLS 1.2 but unfortunately this did not help. We did found a difference in the way we can connect using OpenSSL. On the windows 7 machines that work, we can use the statement; s_client -connect 12.345.678.999:995

On the Windows 2012 server machine we have to include the -servername parameter in the statement, like this;

s_client -servername 12.345.678.999 -connect 12.345.678.999:995

Could the problem have something to do with SNI(Server Name Indication), or the lack of support for this on the Windows 2012 server?

---

You can try https://www.limilabs.com/blog/the-remote-certificate-is-invalid-according-to-the-validation-procedure but I don't think the problem is with the certificate. Windows 2012 supports SSL3 and TLS12.

Maybe turning on System.Net log can help. Add this to you app config:

<?xml version="1.0"?>
<configuration>
      <system.diagnostics>
        <trace autoflush="true"/>
        <sources>
          <source name="System.Net">
            <listeners>
              <add name="TraceFile"/>
            </listeners>
          </source>
        </sources>

        <sharedListeners>
          <add name="TraceFile"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\trace.log"/>
        </sharedListeners>
        <switches>
          <add name="System.Net" value="Verbose" />
      </switches>
    </system.diagnostics>
</configuration>