关于java中ssl握手和行为的问题
我正在使用 https 连接到 https 服务器。
具体来说，我使用 apache httpclient 并配置 ssl 上下文以使用我的密钥库和信任库。
我使用的 https 服务器是 IIS7，并配置为需要客户端身份验证。
我想我已经正确设置了。
无论如何，如果我使用对 IIS 有效的密钥库（即客户端证书）配置 httpClent 的 ssl 上下文，那么连接就没有问题。
现在我的问题如下： 如果我不使用任何客户端证书配置 ssl 上下文以发送到 IIS，则不会与服务器建立连接。但让我思考的是，我希望在代码中看到一些 java 异常，这是由于 hanshake 失败警报造成的。
监视wireshark发生的情况，我看不到从IIS到我的应用程序的证书请求，但我注意到在ServerHelloDone之后所有内容都被加密了。
我没想到会这样。我认为握手通常是明文的。
我使用私钥解密痕迹，并看到来自 IIS 的证书请求，但在多次启动和打开新连接之后。
我的应用发送回长度为 0 的证书作为响应，IIS 使用 TLSv1 已完成进行回复。
之后数据包停止（即似乎通信结束）。
我期待着握手警报。
我的问题是，这是它应有的工作方式吗？或者至少是 IIS 的工作方式？
或者，如果我没有看到警报，我的用例有问题吗？
谢谢
I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.
Now my problem is the following:
If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.
My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
听起来 IIS 仅需要某些 URL 的客户端证书（即 example.com/foo，但不是 example.com/bar）。
在最初的握手中，它不知道你请求的是哪个url，所以它不需要证书。当它发现您正在请求受限资源 (/foo) 时，它会重新握手，需要证书。
但是，我仍然希望发生握手失败。
It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).
In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.
However, I would still expect a handshake_failure to occur.
正如我在 答案中所说这个问题，据我记得，IIS是通过重新协商来获取客户端证书的。您应该能够使用
netsh和clientcertnegotiate=enable更改此行为（具体取决于您使用的 IIS 版本）。您可能也对此类似问题感兴趣。
As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using
netshandclientcertnegotiate=enable(depending on the version of IIS you're using).You might also be interest in this similar question.
未能提供证书来响应 CertificateRequest 不是 SSL 协议错误，因此不存在握手错误。 SSL 库添加了“要求”而不是仅仅“需要”客户端证书，如果您不发送证书，它们所能做的就是关闭连接。
Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.