基于OpenSSL实现类SSH自签名证书握手的技术问题咨询

多数SSH客户端连接未知主机时，会检测到未知/自签名证书，并询问用户是否继续连接。我正在为自制本地文件传输程序添加加密功能，目标是实现和SSH客户端相同的行为，目前参考OpenSSL的echo demo开发。需要说明的是，这里讨论的不是SSH证书用户认证，而是握手与数据加密环节，本质是复刻SSH的**信任首次使用（TOFU）**提示验证机制。我知道SSH底层不使用SSL，但部分实现会借助OpenSSL处理加密，选择SSL是为了减少加密实现错误，比从头开发加密逻辑更稳妥。

技术疑问及分析 #

问题1：证书域名的处理方式 #

若证书需包含域名，客户端应如何生成证书？是为每个网络接口IP生成证书，还是直接忽略域名？

我的初步分析：可以直接忽略域名。原因在于SSH场景下，主机IP可能随DHCP变动，且网络攻击者可伪造IP。在OpenSSL的echo示例中，通过调用SSL_set_tlsext_host_name和SSL_set1_host并传入客户端连接的任意主机名，本质上绕过了证书通用名称（Common Name）的检查，这种方式适配本地场景的灵活性更高。

问题2：证书传输至客户端的可行方案 #

证书如何传输至客户端？我设想了三种方案：

• 方案一：SSL握手失败后，客户端提取服务器证书并询问用户是否存储；用户确认存储后重启连接，若后续连接检测到证书与已存储的一致则跳过检查，最终建立SSL会话。
• 方案二：SSL握手失败后，客户端通过未加密套接字向服务器请求自签名所用的CA证书；用户允许后将该CA证书存入本地信任库，再重启SSL会话，此时服务器证书可通过CA验证。
• 方案三：调用SSL_CTX_set_verify并传入SSL_VERIFY_NONE强制SSL握手成功；若后续证书验证失败，无需重连直接执行方案一的存储确认逻辑，或通过安全通道传输CA证书执行方案二的信任库配置逻辑。

注意：上述方案在用户未确认服务器证书一致性前，均易受MITM攻击，这与SSH客户端的原生行为一致。

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