关于java中ssl握手和行为的问题

Question

我正在使用 https 连接到 https 服务器。
具体来说，我正在使用 apache httpclient 并配置 ssl 上下文以使用我的密钥库和信任库。
我使用的 https 服务器是 IIS7，并配置为 require 客户端身份验证。
我想我已经正确设置了。
无论如何，如果我使用对 IIS 有效的密钥库（即使用客户端证书）配置 httpClent 的 ssl 上下文，那么连接就没有问题。

现在我的问题如下： 如果我不使用任何客户端证书配置 ssl 上下文以发送到 IIS，则与服务器没有连接。但让我想到的是，由于 hanshake 失败警报，我希望在代码中看到一些 java 异常。
监视使用wireshark 发生的情况，我看不到从IIS 到我的应用程序的证书请求，但我注意到在ServerHelloDone 之后所有内容都被加密了。
我原本没想到。我认为握手通常是明文。
我使用私钥解密跟踪，我看到了来自 IIS 的证书请求，但在多次启动和打开新连接之后。
我的应用程序将长度为 0 的证书作为响应发回，IIS 使用 TLSv1 Finished 回复。
之后数据包停止（即似乎通信结束）。
我期待一个握手警报。

我的问题是，这是它应该如何工作或至少 IIS 是如何工作的？
或者，如果我没有看到警报，我的用例有问题？

谢谢

Answer 1

听起来 IIS 只需要特定 URL 的客户端证书（例如，example.com/foo，而不是 example.com/bar）。

在最初的握手中，它不知道你请求的是哪个 url，所以它不需要证书。当它发现您正在请求受限资源 (/foo) 时，它会重新握手，需要证书。

但是，我仍然希望会发生 handshake_failure。

Answer 2

未能提供证书以响应 CertificateRequest 不是 SSL 协议错误，因此不存在 handshake_error。 SSL 库添加了“需要”而不是“需要”客户端证书，如果您不发送，它们所能做的就是关闭连接。

Answer 3

正如我在an answer to this question 中所说，据我所知，IIS 使用重新协商来获取客户端证书。您应该能够使用 netsh 和 clientcertnegotiate=enable 更改此行为（取决于您使用的 IIS 版本）。

您可能也对此similar question感兴趣。