Boost's ASIO + SSL don't work in some conditions - c++

Question

There is a client/server application written using Boost's ASIO (Boost v.1.48) + OpenSSL (v.1.0.0d). Complete OpenSSL (dynamic/static libraries and binaries) is custom built, the after-build tests are passed correctly and it links to the client and the server statically. ASIO code works in asynchronous mode. All ASIO's SSL contexts use the boost::asio::ssl::context::sslv23
method. The problem description is the following.
Configuration 0
The server: works under Win7 Prof SP1 (Comp0). It uses a self-signed private key (PK0) and a public certificate (PC0) generated by the custom built OpenSSL binaries mentioned above. The server has a infinite timeout.
The client: works under WinXP Prof SP3 (Comp1). It uses the servers public certificate (PC0). The client has 20 secs timeout.
The clients connects successfully to the server but closes the connection by the 20 secs timeout in the SSL's handshake method (boost::asio::ssl::stream::async_handshake). FAIL.
Configuration 1
Both the server and the client run on the same Win7 Prof SP1 (Comp0), use the same ethernet interface and the same PK0/PC0 as in the configuration 0.
The clients successfully connects handshakes, sends/receives data and closes the connection. SUCCESS.
Configuration 2
The server: works under Win7 Prof SP1 (Comp0). It uses a self-signed private key (PK1) and a public certificate (PC1) generated by the custom built OpenSSL binaries BUT the PK1 and PC1 are generated a half of a year ago. PK0/PC0 are generated today. All the keys are generated by the same OpenSSL binaries (v.1.0.0d).
The client: works under WinXP Prof SP3 (Comp1). It uses the servers public certificate (PC1).
The clients successfully connects handshakes, sends/receives data and closes the connection. SUCCESS.
Configuration 3
Both the server and the client run on the same Win7 Prof SP1 (Comp0), use the same ethernet interface and the same PK1/PC1 as in the configuration 2.
The clients successfully connects handshakes, sends/receives data and closes the connection. Obviousely SUCCESS.
Changing the OpenSSL version to the latest stable release (v.1.0.0g) gives the same results.
The problem is not working configuration 0. Has anyone ever had such problem? Are there any ideas where can be the problem cause? In which direction is necessary to move to fix the problem?
Update #1. The code compiled using the tlsv1 method instead of the sslv23 one does not work in the Configuration 0 also.
Final Update. The problem is fixed. The cause is that the Comp1's system date was in the past, i.e. the PK0/PC0 are issued in future for this computer and OpenSSL fails in the handshake procedure. PC1 is issued in the past for the Comp1 and it works with it without problems. To diagnose the problem cause I used the following command executed on the client computer:openssl s_client -connect server_ip:server_port, where server_ip is the server address and server_port is the the server listening port. Now a task is to find a reason why handshake times out rather than returns an error. But it is another story. I hope my post will help someone in future.

Answer 1

The problem is fixed. The cause is that the Comp1's system date was in the past, i.e. the PK0/PC0 are issued in future for this computer and OpenSSL fails in the handshake procedure. PC1 is issued in the past for the Comp1 and it works with it without problems. To diagnose the problem cause I used the following command executed on the client computer:openssl s_client -connect server_ip:server_port
, where server_ip is the server address and server_port is the the server listening port. Now a task is to find a reason why handshake times out rather than returns an error. But it is another story. I hope my post will help someone in future.