不同OpenSSL版本下客户端重连后SSL_read返回SSL_ERROR_SSL错误排查

我基于TCP套接字开发了Linux客户端-服务器应用：

• 使用OpenSSL库在建立连接前验证证书和密钥
• 服务器端使用OpenSSL 1.1.0版本，客户端使用OpenSSL 3.0.8版本，初始状态下双方可正常连接

场景说明 #

当用户在服务器端执行操作后，服务器会自行重启（预期行为），导致客户端与服务器的SSL连接短暂中断。客户端尝试重新连接，发送握手包后收到服务器回复，连接建立成功，但后续调用SSL_read()时返回-1失败：

/* --> SSL_read() returns -1 */
int read_ret = SSL_read(sslObj, buffer, size); 
if (read_ret <= SSL_ERROR_NONE)
{
        /* --> SSL_get_error() returns 1 means SSL_ERROR_SSL*/
        int read_error = SSL_get_error(sslObj, read_ret);

        /* --> strerror_r() returns "Resource temporarily unavailable" with errno : 11 */
        strerror_r(errno , systemError, bufferSize);
}

连接建立后，客户端调用SSL_read()读取数据时，触发SSL_ERROR_SSL错误，同时系统错误为“Resource temporarily unavailable”（errno:11），且该问题循环出现：客户端重连→连接建立→SSL_read失败→再次重连。

疑问 #

1. 客户端与服务器使用不同OpenSSL版本是否会导致该问题？（我认为OpenSSL版本具备向后兼容性）
2. 根据OpenSSL官方说明，SSL_ERROR_SSL表示SSL库发生不可恢复的致命错误（通常是协议错误），错误队列包含更多信息，此时不可再执行I/O操作，也不能调用SSL_shutdown()。这是否属于OpenSSL库错误？该如何处理这种场景？
3. 哪些情况会触发errno:11的“Resource temporarily unavailable”系统错误？

1. 跨OpenSSL版本兼容性问题 #

OpenSSL确实承诺向后兼容性，但1.1.0到3.0.8属于大版本跨越（1.1.x系列到3.x系列），部分协议细节或默认配置可能存在差异：

• 3.0.x默认禁用了一些旧的加密套件或协议版本（比如TLS 1.0/1.1），而1.1.0可能仍默认支持；如果服务器重启后配置未明确指定兼容的协议套件，可能导致握手后协议协商出现隐性不兼容，触发后续SSL_read()错误。
• 3.0.x对SSL上下文的初始化、证书验证逻辑有细节调整，若客户端或服务器的证书/密钥处理逻辑在跨版本下存在细微差异，也可能引发后续的SSL层错误。
  不过初始连接正常，说明基础兼容没问题，重启后的问题更可能是服务器重启后的状态异常或协商细节冲突，而非单纯版本不兼容。

2. SSL_ERROR_SSL的定位与处理 #

SSL_ERROR_SSL不一定是OpenSSL库本身的错误，更多是SSL协议交互过程中的致命错误（比如握手不完整、数据包损坏、协议版本不匹配、加密套件协商失败后的后续I/O）。

排查步骤： #

• 提取OpenSSL错误队列的详细信息：调用ERR_print_errors_fp(stderr)或循环调用ERR_get_error()获取错误码，这些信息能精准定位是协议错误、证书问题还是加密套件不兼容。
• 检查服务器重启后的SSL上下文初始化逻辑：确认服务器重启后是否正确加载了证书、密钥，是否复用了旧的套接字资源，或者是否存在SSL状态未正确重置的情况。

处理方式： #

• 一旦触发SSL_ERROR_SSL，必须立即关闭SSL对象和底层TCP套接字，不能再进行任何I/O操作。
• 调整重连逻辑：重连时不要复用旧的SSL对象，必须重新创建SSL上下文、SSL对象，重新完成完整的握手流程；同时增加重连间隔的退避机制（比如指数退避），避免短时间内频繁重连导致服务器端资源未完全初始化。

3. errno:11（EAGAIN/EWOULDBLOCK）的触发场景 #

errno 11对应的是EAGAIN或EWOULDBLOCK，表示当前操作没有数据可用或资源暂时不可用，常见场景包括：

• SSL套接字设置为非阻塞模式时，SSL_read()尝试读取但服务器端尚未发送数据，此时会返回SSL_ERROR_WANT_READ，但如果同时伴随SSL_ERROR_SSL，说明是SSL层的错误叠加了非阻塞状态。
• 服务器重启后，虽然TCP连接建立，但SSL握手并未真正完成（比如服务器端SSL上下文未完全初始化，导致握手后SSL状态异常），此时客户端调用SSL_read()会触发资源不可用的错误。
• 底层TCP连接存在半开状态：服务器重启后，TCP连接看似建立，但服务器端并未真正完成SSL会话的初始化，导致客户端读取时无有效数据返回。

内容的提问来源于stack exchange，提问作者Roger