当握手中没有发送“客户端请求”时，Chrome如何知道提供客户端证书？

Question

这个问题让我感到困惑，而我的客户端应用程序和外部服务器之间的相互SSL故障。

当我的应用程序尝试连接到外部服务器的rest API时，我们调用它https://www.server.com/api/resolve-我希望与服务器hello一起发送“证书请求”握手元素。就我和服务器之间所有通信量的tcpdump所知，它没有被发送。只发送“服务器Hello，证书，证书状态，服务器密钥交换，服务器Hello Done”：

TLSv1的tcpdump。2握手：https://i.stack.imgur.com/50Ous.png

然而，当我试图在Chrome中访问相同的API URL时，浏览器会显示一个框，要求我选择客户端证书进行相互身份验证。当我捕捉到该握手的转储，直到浏览器提示我输入证书时，我仍然没有看到服务器发送的“证书请求”：

Tcpdump浏览器导航到API：https://i.stack.imgur.com/hvOEx.png

在Chrome中选择证书后，我被引导到网站，但是我也没有看到在我的TLS1.2捕获中发送的客户端“证书”。

我的问题是，Chrome有没有办法知道服务器请求的客户端证书，如果该请求没有在TLS握手中发送？

或者，wireshark可能在骗我吗？当我测试时，例如：https://client.badssl.com/它请求相互SSL，我在服务器密钥交换之后立即看到证书请求，这与我应该看到的完全一样。我在TLSv1中注意到。2 RFC(https://www.rfc-editor.org/rfc/rfc5246)报告指出：

"特别是，证书和证书请求握手消息可能大到需要碎片。"

但这应该与Wireshark显示TLS信息的方式无关。

Answer 1

在应用程序数据之后的数据包捕获中有几个加密的握手消息。这很可能意味着服务器本身在默认情况下不会请求客户端证书，而是只针对特定的URL请求证书。

在这种情况下，首先在没有证书请求的情况下进行TLS握手。握手完成后，客户端通过加密的连接发送HTTP请求，该连接是数据包捕获中的应用程序数据。服务器将确定请求的网址需要客户端证书，并启动重新协商，即另一次TLS握手，但这次是使用证书请求。但是由于连接已经加密，这种重新协商只能以加密握手消息的形式显示，如果不解密流量，就无法看到详细信息。