An error is returned when attempting to create a secure SSL or TLS connection indicating that the SocketTools component cannot establish a security context. This error can occur for several reasons, depending on the server configuration and the version of Windows the application is running on.
More Information
When the application attempts to connect to a server, the connection fails with error code 12102 (0x80042F46) which means that it cannot establish a security context. This is a general error that can occur when SocketTools is unable to successfully complete the initial handshake with the server in which certificate information is exchanged and the encryption ciphers are selected for the session. This error may occur under the following circumstances:
1. The server is not accepting new connections, or it does not support secure connections on the port number that was specified. If the server is not accepting new client connections, it may accept the TCP connection and then immediately close it, or return an error message and close the connection. If the server is not configured to accept secure connections, it will not know how to respond to the initial TLS handshake and this will cause the connection to fail.
2. The server is not configured for implicit TLS connections on the specified port number. If the server was configured to use explicit TLS, then the initial connection is made with the client connecting normally using a standard (non-secure) connection. To initiate a secure session, the client must send a specific command to the server that tells the server it wants a secure connection and then follows that with the TLS handshake. SocketTools supports both implicit and explicit TLS sessions, and by default will select the correct option based on the port number used. However, if the server has a non-standard configuration or is using an alternate port number, it may be necessary to explicitly specify the correct security option when calling the Connect method or function.
3. The server does not understand how to handle requests for TLS version 1.2. By default, SocketTools will only use the latest version of TLS and the strongest encryption ciphers available to both the client and server. When SocketTools advertises that it would like to use TLS 1.2, some older server software may not correctly negotiate for an earlier version of TLS and instead reject the connection or fail unexpectedly. This is a flaw in the server software, not SocketTools, and it is recommended that you upgrade the server if possible. An alternative is to set your application compatibility to Windows XP SP3 and see if the connection succeeds. This tells SocketTools to not use the current versions of TLS and it will only attempt to use older, less secure options. SocketTools 9.0 and later will only request TLS 1.2 by default. TLS 1.0 will only be used if the application is running on an older, unsupported version of Windows.
4. The client application is running on Windows XP or Windows Server 2003 and is connecting to a server that uses certificates that were signed using SHA-256, or has been configured to not permit connections using SSL 3.0, TLS 1.0 or the RC4-SHA cipher suite. Servers may be configured to require connections using the current version of TLS and reject less secure cipher suites. Because Windows XP and Windows Server 2003 do not support TLS 1.2 or AES encryption, the server may refuse the connection attempt. If a secure connection to the same server is successful when the application runs on Windows 7 or later versions of Windows, this is likely the cause of the failure.
See Also
Support for TLS 1.2 on Windows XP
Windows and Supported TLS Versions
Connections Fail After Upgrading to Apache 2.4
Unable to Connect to Office 365 Servers