一、先明确mTLS的核心逻辑 #

mTLS双向认证必须要有带私钥的客户端证书——这里要划重点：私钥是你生成CSR时自己本地保留的，第三方根本不会也不能给你。你提交CSR给第三方，他们只是用自己的CA给你的CSR签名，返回的是签名后的客户端证书（可能打包在P7B里），私钥从始至终都该在你手里。

二、当前问题的修复步骤 #

• 找回生成CSR时的私钥：
  你当初生成.csr文件的时候，肯定同时生成了对应的私钥（一般是.key或.pem格式），这才是mTLS的核心凭证。要是找不到了，只能重新生成CSR和私钥对，再提交给第三方重新签名。
• 合并私钥与第三方返回的证书：
  把你本地的私钥和从P7B里提取出的签名客户端证书，合并成PKCS#12（.pfx/.p12）格式，这是多数脚本/客户端支持的带私钥证书格式。
  用OpenSSL的示例命令：

  openssl pkcs12 -export -in 你的签名证书.pem -inkey 你的私钥.key -out 客户端证书.pfx
  

• 调整脚本配置：
  别再用证书指纹，直接引用生成的.pfx文件（如果设置了密码就加上密码参数），这样客户端才能正确加载带私钥的证书完成握手，解决"The request was aborted: Could not create SSL/TLS secure channel"错误。

三、私钥无法找回时的替代方案 #

如果私钥彻底丢失，且第三方不让重新申请CSR，可以和对方协商以下替代方案：

• API密钥+单向TLS：在HTTP请求头里加入第三方提供的密钥，搭配普通HTTPS（单向TLS），既能加密传输又能完成身份认证。
• IP白名单+单向TLS：让第三方把你方服务器IP加入访问白名单，只允许该IP请求，再用普通HTTPS加密数据传输。
• XML数字签名+单向TLS：用你本地新生成的私钥给XML负载做数字签名，第三方用你的公钥验证签名有效性，同时用HTTPS加密传输通道，实现身份校验和数据完整性保障。

内容的提问来源于stack exchange，提问作者Ma Kristel Mirabel