【发布时间】：2014-11-11 16:06:34
【问题描述】：
我阅读了 TLS 1.2 RFC，但我找不到（或理解）客户端证书身份验证的工作原理。
我的理解是服务器可能会请求客户端证书并且客户端应该提供它，但它到底提供了什么？客户如何证明他拥有私钥（我假设他遇到了一些挑战并对其进行了加密，但他究竟加密了什么）？
如果有人能对协议的这一部分有所了解，我会很高兴。
编辑： 我想要实现的是中间人（就像 fiddler 为服务器证书所做的那样）。
【问题讨论】：
【发布时间】：2014-11-11 16:06:34
【问题描述】：
我可以从 openssl wiki 复制/粘贴： https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Client_Authentication
基本上，客户端将客户端证书发送到与服务器给出的 CA DN 匹配的服务器。然后客户端发送一个证书验证，使用它的私钥来证明他拥有它。
客户端证书身份验证要求客户端拥有证书并拥有相应的私钥。客户端从不发送其私钥，而是使用它来证明他拥有证书中公布的相应公钥对。
他消化了什么？到目前为止的整个握手交流的摘要。 如果服务器设法用公钥验证这一点，并且它与迄今为止的整个握手摘要相匹配（在服务器端计算），那么我证明两件事：
- 客户拥有私钥（否则用公钥解密是不正确的）
- 客户端在此握手的另一端，它可以防止客户端证书验证在另一次握手时重放。
所以是的，挑战实际上是整个握手消息。
【讨论】：
-
所以当客户端证书被激活时我不能做“中间人”？ （我可以使用服务器证书，因为我正在客户端上安装我的 CA）？
-
您需要让您的服务器信任您，就像您为客户端所做的那样，然后创建具有服务器信任的客户端证书并发挥您的作用。否则，我看不出您如何在不破坏其私钥的情况下按原样传递客户端证书身份。您仍然可以尝试按原样传递 CertificateVerify 并查看服务器是否实际执行了验证（一些错误的实现可能会错过它）。
-
你设法用客户证书做中间人，我很想知道你是怎么做到的。