固定证书与双向验证两种 HTTPS 高阶场景的处理

常规证书安装解决 95% 的 HTTPS 抓包问题，剩下 5% 藏在两个高阶场景里：固定证书和双向验证。Reqable 对两者都提供了配置入口，但有明确的能力边界。

场景一：固定证书（SSL Pinning）

原理：应用客户端在代码里「钉死」了服务器的 SSL 证书（或公钥），只接受指定签发的证书。Reqable 中间人重签的证书自然过不了验证——这是应用故意防中间人的安全机制。

Reqable 的处理：如果你拥有目标服务器的 SSL 证书（公钥证书 + 私钥），可以把它配置到 Reqable 的 SSL 证书（服务端） 中，让中间人用真证书应答。没有服务器私钥时，固定证书的 App 无法抓包，这属于正常的安全边界，不是配置问题。

表现特征：装好证书后唯独某个 App 的请求全部 SSL 失败，浏览器和其他 App 正常——大概率就是 Pinning。

场景二：双向验证（mTLS）

原理：常规 TLS 只验证服务器身份；双向验证要求客户端也上传证书给服务器验证。Reqable 的中间人默认不会上传客户端证书，服务器会拒绝连接。

Reqable 的处理：把你拥有的客户端 SSL 证书（私钥可选）配置到 Reqable 的 SSL 证书（客户端） 中，中间人即可代客户端向服务器出示证书。

场景三：应用内置 CA 验证

第三类：应用不用系统证书库，而是内置自己的 CA Store。最典型的是 Firefox——好在其设置里提供了导入第三方 CA 的开关（处理步骤见 Chrome/Firefox 证书不信任）。没有提供开关的应用只能由开发商解决，客户端侧无解。

配置入口与建议

SSL 证书（服务端/客户端）的配置在应用的证书管理相关菜单中，具体入口以应用内界面为准。排障顺序建议：

1. 先确认基础证书安装没问题（电脑端装证书 / Android / iOS）；
2. 按现象对号入座：全部请求失败还是单个 App 失败（SSL 握手失败六大原因）；
3. 确认是 Pinning/mTLS 后再走本篇的证书配置。

这三种场景的原始说明来自官方 FAQ 的 SSL 分册，细节以官方最新文档为准。