案例 1 涉及使用基于 secp384 的 EC 证书对客户端和服务器进行 TLS + 客户端证书身份验证。在这种情况下，当通过提琴手监控流量时，提琴手完全缺少隧道/握手以及加密流量（好像什么都没发生一样）。通过单独监控客户端和服务器，我们知道存在真实流量。
情况2涉及相同的客户端进程，相同的服务器进程，相同的服务器证书，但禁用了客户端证书身份验证。在这种情况下，所有流量以及初始握手都在 Fiddler 中捕获。
这是 Fiddler 的已知限制吗？如果是，我还能如何捕获案例 1 中发生的 TLS 握手？如果没有，我是否缺少 Fiddler 中的设置？我也有C:\Users\<username>\My Documents\Fiddler2\ClientCertificate.cer设置...
Fiddler 通过为目标服务器即时生成虚假证书来捕获 HTTPS 流量，从而运行完整的中间人攻击。这要求将客户端配置为接受 Fiddler 控制的 CA 作为受信任的 CA，如文档中所述。
这种拦截会破坏客户端证书。当 SSL/TLS 中有客户端证书时，客户端在技术上（在握手期间）签署相当于迄今为止所有接收和发送的握手消息的哈希值；然后，客户端计算的签名将覆盖（除其他外）从客户端看到的服务器证书，即 Fiddler 生成的假证书，而不是真正的服务器证书。因此，客户端签名将与服务器看到的握手消息不匹配。
如果要相信文档，则 Fiddler可以解决此问题，但这需要 Fiddler 重新计算客户端签名。这仅在 Fiddler 有权访问客户端的private key时才有效。“.cer”文件是不够的；需要私钥。文档有点不清楚；我的猜测是 Fiddler 使用“.cer”文件来知道要使用什么客户端证书，然后将在本地用户的证书存储中查找该证书和私钥（这就是为什么 Fiddler 的文档说您应该首先将证书“作为 .pfx 文件”导入，即使用其相应的私钥，然后只导出“ .cer”文件）。在任何情况下，如果无法访问客户端私钥，Fiddler 在与服务器通信时将无法伪装成真正的客户端。
现在 Fiddler 也可能对EC 证书有限制；我不知道。从我上面的解释来看，Fiddler 在与正版服务器通信时必须作为 TLS 客户端运行，所以如果有客户端 EC 证书，那么 Fiddler 的代码必须支持它，这意味着 Fiddler 必须能够生成 ECDSA 签名。
从文档中我们看到，私钥保留在客户端机器（Windows 系统）的内部。因此，任何签名生成都需要通过 Windows 提供的加密 API。Windows 有两个完全不同的 API：CryptoAPI和CNG。CryptoAPI 是旧的；CNG 是在 Windows Vista 和 2008 中引入的。从应用程序（例如 Fiddler）的角度来看，使用 CNG 存储和管理的私钥只能用于特定的函数调用；仅知道 CryptoAPI 的应用程序不能使用 CNG 存储的私钥。
不幸的是，CryptoAPI 不支持椭圆曲线。基于 EC 的密钥只能通过 CNG 使用。此外，据说 Fiddler 是用 .NET 编写的，而 .NET 的加密 API 仅依赖于 CryptoAPI（您可以使用 CNG，但必须通过显式调用本机 DLLncrypt.dll和.NET 来实现bcrypt.dll）。因此，我认为 Fiddler 仅使用 CryptoAPI 并因此可能仅支持客户端证书的 RSA 和 DSA 密钥，而不是 EC 密钥，这很合理。