这是因为在 SSL/TLS 连接中，非对称密钥交换使用服务器的公钥来交换预主密钥。客户端证书仅在服务器请求时用于客户端身份验证。预主密钥用于生成会话密钥。 这就是为什么您需要服务器的私钥，而不是客户端的。

典型的 SSL/TLS 密钥交换：

请注意，在上述交换中，只有服务器发送其证书。客户端密钥交换消息是使用服务器公钥加密的预主密钥。

带客户端身份验证的 SSL/TLS 密钥交换

在上面的交换中，我们看到在服务器发送它的证书之后，它还提供了一个 CertificateRequest 消息。此消息要求客户端提供其公共证书。它以 ClientKeyExchange 消息作为典型握手中的响应，然后发送一个 ClientVerify 消息，该消息对散列密钥交换数据进行签名。然后服务器使用这个签名来验证客户端。

客户端或服务器从不使用客户端的公钥来加密握手中的任何信息。因此，不需要会话解密。

因为客户端在协商的第 4 阶段（维基百科）使用服务器公钥加密通信：

4 - 使用迄今为止在握手中生成的所有数据，客户端（在服务器的合作下，取决于使用的密码）为会话创建预主密钥，用服务器的公钥加密它（从服务器的证书，在步骤 2) 中发送，然后将加密的 pre-master secret 发送到服务器。

在协商结束时，双方生成一个会话密钥，用于加密通信。

我认为带有服务器私钥的wireshark可以在握手期间选择这个会话密钥。

塞德里克。

客户端私钥仅在使用客户端证书身份验证时使用，并且仅用于签名，不用于解密。（如果使用 RSA/DSA 密钥）（如果使用静态 DH，这是可能的，但任何 TLS 服务器或客户端都不支持静态 DH）

假设在服务器端（或理论上是客户端，但这更难并且不一定总是有效）设置了适当的 SSL/TLS 参数，拥有服务器私钥仍然不允许您解密任何流量，除非您正在执行主动攻击。

这实际上取决于客户端和服务器之间是否协商了前向安全性 (FS)。不能保证客户端协商前向安全算法。IE 在选择 FS 算法方面是出了名的糟糕，它依赖于服务器来确定各种选项的优先级。因此，如果您在服务器上设置 SSL 选项时非常小心，并且您的服务器支持将一种算法优先于另一种算法，那么甚至可以在 IE 上协商前向安全性。

（Qualsys 有一个出色的工具，可以模拟主要浏览器与网站的协商。） https://www.ssllabs.com/ssltest/index.html

如果服务器支持，基本上所有其他主要浏览器（Chrome、Firefox、Safari 等）通常都会选择前向安全性，因此仅使用服务器的私钥解密是不可能的。