Boost 的 ASIO + SSL 在某些情况下不起作用
有一个使用 Boost 的 ASIO (Boost v.1.48) + OpenSSL (v.1.0.0d) 编写的客户端/服务器应用程序。完整的 OpenSSL（动态/静态库和二进制文件）是定制构建的，构建后测试正确通过，并且静态链接到客户端和服务器。 ASIO 代码以异步模式工作。所有 ASIO 的 SSL 上下文都使用
boost::asio::ssl::context::sslv23配置0
服务器：工作在Win7 Prof SP1 (Comp0)下。它使用由上述自定义构建的 OpenSSL 二进制文件生成的自签名私钥 (PK0) 和公共证书 (PC0)。服务器有无限超时。 客户端：在 WinXP Prof SP3 (Comp1) 下工作。它使用服务器公共证书 (PC0)。客户端有 20 秒超时。
客户端成功连接到服务器，但在 SSL 握手方法 (boost::asio::ssl::stream::async_handshake) 中的 20 秒超时后关闭连接。 失败。
配置1
服务器和客户端都运行在同一个Win7 Prof SP1（Comp0）上，使用与配置0相同的以太网接口和相同的PK0/PC0。
客户端成功连接握手，发送/接收数据并关闭连接。 成功。
配置2
服务器：工作在Win7 Prof SP1（Comp0）下。它使用自定义构建的 OpenSSL 二进制文件生成的自签名私钥 (PK1) 和公共证书 (PC1)，但 PK1 和 PC1 是半年前生成的。 PK0/PC0 今天生成。所有密钥均由相同的 OpenSSL 二进制文件 (v.1.0.0d) 生成。 客户端：在 WinXP Prof SP3 (Comp1) 下工作。它使用服务器公共证书 (PC1)。
客户端成功连接握手、发送/接收数据并关闭连接。 成功。
配置3
服务器和客户端都运行在同一个Win7 Prof SP1（Comp0）上，使用与配置2相同的以太网接口和相同的PK1/PC1。
客户端成功连接握手，发送/接收数据并关闭连接。显然成功。
将 OpenSSL 版本更改为最新的稳定版本 (v.1.0.0g) 会得到相同的结果。
问题是配置 0 不起作用。有人遇到过这样的问题吗？有什么想法可能是问题原因吗？需要朝哪个方向移动才能解决问题？
更新#1。使用 tlsv1 方法而不是 sslv23 方法编译的代码在配置 0 中也不起作用。
最终更新。问题已解决。原因是Comp1的系统日期是过去的，即该计算机的PK0/PC0是未来发布的，并且OpenSSL在握手过程中失败。 PC1 过去是针对 Comp1 发布的，并且可以毫无问题地与它配合使用。为了诊断问题原因，我使用了在客户端计算机上执行的以下命令：
openssl s_client -connect server_ip:server_portThere 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::sslv23method. 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题已解决。原因是Comp1的系统日期是过去的，即该计算机的PK0/PC0是未来发布的，并且OpenSSL在握手过程中失败。 PC1 过去是针对 Comp1 发布的，并且可以毫无问题地与它配合使用。为了诊断问题原因，我使用了在客户端计算机上执行的以下命令：
, 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.
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:
, 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.