结合你给出的错误日志、代码片段和抓包信息，咱们可以按以下步骤一步步定位这个随机出现的SSL_ERROR_SSL（错误码1）问题——底层错误提示明确指向SSL3_GET_CLIENT_CERTIFICATE:no certificate returned：

1. 检查客户端证书强制验证配置 #

首先确认OpenSIPS的TLS配置里是否开启了强制要求客户端证书。如果开了这个选项，但客户端在第二次请求时没正确发送证书，就会触发这个错误：

• 去OpenSIPS配置文件里找这些关键参数：

  tls_require_client_certificate=yes
  tls_verify_client_certificate=yes
  

• 注意：有些客户端可能在首次握手时正常发送了证书，但在会话复用或者重传场景下就不再携带，这大概率是客户端的会话复用逻辑存在bug。

2. 排查TLS会话复用与重传的兼容性问题 #

抓包显示所有TLS包都有重传，且你读取的是分片包的第二部分，这可能和TCP分片、TLS记录层的处理逻辑直接相关：

• 检查OpenSIPS依赖的OpenSSL版本是否存在TCP分片处理的已知bug，比如某些旧版本OpenSSL在处理分片的TLS记录时，会误触发证书验证失败的逻辑。
• 验证客户端在重传时是否没有完整发送TLS记录，导致OpenSIPS的SSL_read在处理分片包时，错误判断为客户端未返回证书。

3. 审核证书链与信任配置 #

就算客户端发送了证书，OpenSIPS也可能因为信任链不完整，无法验证客户端证书，从而返回类似错误：

• 确认OpenSIPS配置里tls_ca_list指定的CA证书是否包含客户端证书的签发CA，且证书链是完整的（包括中间CA证书）。
• 检查客户端证书是否过期、格式是否正确（比如是否为PEM格式，是否包含完整的证书链）。

4. 优化代码中的错误处理逻辑 #

从你提供的代码来看，遇到SSL_ERROR_SSL时直接标记连接为S_CONN_BAD并关闭，但可以补充更详细的日志和恢复逻辑：

• 在default分支中，除了打印错误码，确保完整输出OpenSSL的错误栈（你已经在用tls_print_errstack()，可以确认是否捕获了所有嵌套错误）。
• 遇到SSL_ERROR_SSL时，不要直接关闭连接，可以先尝试重新触发TLS握手（比如调用SSL_do_handshake()），看看能否恢复会话——尤其是如果问题是由分片包导致的话，这个操作可能有效。

5. 排除网络层面的干扰 #

抓包中的重传现象说明网络可能存在丢包、延迟或者MTU不匹配的问题：

• 检查通信双方的MTU设置，是否因TCP分片导致TLS记录不完整。可以尝试调整MTU大小，或者在OpenSIPS中启用fragment_size参数，限制TLS记录的大小以避免分片。
• 排查中间网络设备（防火墙、负载均衡）是否篡改或截断了TLS数据包，比如有些设备在重传时会丢失证书相关的TLS扩展字段。

6. 验证客户端侧的行为 #

联系客户端开发团队，确认客户端在第二次请求时的TLS行为细节：

• 是否在会话复用过程中跳过了客户端证书的发送？
• 重传时发送的TLS记录是否完整？
• 可以让客户端开启TLS调试日志，捕获发送第二条消息时的证书发送情况。

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