搭建TLS 1.2应用MITM代理时遇证书验证失败的解决求助

看起来你在搭建针对TLS 1.2应用的MITM代理时遇到了证书验证的瓶颈，结合你提供的代码和操作步骤，我来梳理几个关键的排查和解决方向：

1. 检查应用的X509_STORE是否包含你的自签名CA #

你的证书验证代码中使用了(X509_STORE*)Store，但这个Store的初始化逻辑是关键：

• OpenSSL默认的证书存储不会自动读取Windows系统的"受信任根证书颁发机构"（除非应用做了Windows特定适配）
• 你需要手动将自签名根CA加载到这个Store中，示例代码如下：

  // 加载根CA证书文件
  X509 *ca_cert = PEM_read_X509_FILE("path/to/your/ca.crt", NULL, NULL, NULL);
  if (ca_cert != NULL) {
      int add_result = X509_STORE_add_cert((X509_STORE*)Store, ca_cert);
      if (add_result != 1) {
          // 处理证书添加失败的情况
      }
      X509_free(ca_cert);
  } else {
      // 处理根CA文件加载失败的情况
  }
  

• 如果应用需要依赖Windows系统证书存储，可以使用OpenSSL的Windows专属函数X509_STORE_load_system_cert_store来加载系统级受信任CA。

2. 确保代理证书包含正确的SAN扩展 #

TLS 1.2规范要求证书必须通过**Subject Alternative Name（SAN）**匹配目标IP/域名，仅设置Common Name（CN）已无法满足现代验证逻辑：

• 用以下命令检查代理证书的SAN字段：

  openssl x509 -in cert.pem -text -noout
  

  确认输出中存在X509v3 Subject Alternative Name，且包含所有你要代理的目标IP（格式为IP:xxx.xxx.xxx.xxx）
• 如果缺少SAN，需要修改OpenSSL配置文件（如openssl.cnf），添加：

  [v3_req]
  subjectAltName = IP:目标IP1, IP:目标IP2, IP:目标IP3
  

  重新签署证书时指定该配置：

  openssl x509 -req -in proxy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out cert.pem -days 365 -sha256 -extfile openssl.cnf -extensions v3_req
  

3. 验证证书链的完整性 #

代理返回给应用的证书必须是完整的链（代理证书 + 根CA证书），否则应用无法完成信任链验证：

• 将代理证书和根CA证书拼接成完整链文件full_chain.pem（顺序：代理证书在前，根CA在后）
• 在代理的SSL上下文中加载完整证书链：

  if (SSL_CTX_use_certificate_chain_file(proxy_ssl_ctx, "path/to/full_chain.pem") != 1) {
      // 处理证书链加载失败
  }
  

4. 检查证书的Extended Key Usage（EKU） #

代理证书必须包含TLS Web Server Authentication的EKU扩展，否则应用可能拒绝信任：

• 用之前的openssl x509 -text命令检查证书，确认X509v3 Extended Key Usage字段中存在TLS Web Server Authentication
• 如果缺少，可在OpenSSL配置的[v3_req]段添加：

  extendedKeyUsage = serverAuth
  

关于openssl s_client错误的补充说明 #

你提到直接连接原IP时openssl也报verify error:num=20/21但原应用正常，这是因为：

• openssl s_client默认使用自身的CA库（如系统默认的ca-certificates.crt），而原应用可能使用Windows系统的证书存储，两者的信任列表不一致
• 你指定CA文件时验证通过，说明证书本身是有效的，问题核心还是在应用的证书验证逻辑未加载你的自签名CA

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