How does Chrome know to provide Client Certificate when no "Client Request" is sent in handshake?

Question

This question has puzzled me while looking into a Mutual SSL failure between my client app and an external Server.

When my app tries to connection to the external server's rest API - let's call it https://www.server.com/api/resolve - I expect a "Certificate Request" handshake element to be sent with their Server hello. As far as I can tell from a tcpdump of all traffic between me and the server, it is not sent. Only a "Server Hello, Certificate, Certificate Status, Server Key Exchange, Server Hello Done" is sent:

tcpdump of TLSv1.2 handshake: https://i.stack.imgur.com/50Ous.png

However when I try to access that same API URL in Chrome, the browser displays a box asking me to select my client certificate for mutual authentication. When I capture a dump of that handshake up to the point where the browser prompts me for a certificate, I still see no "Certificate Request" sent by the Server:

Tcpdump of browser navigation to API: https://i.stack.imgur.com/hvOEx.png

After selecting a certificate in Chrome, I'm directed to the site, however I see no Client "Certificate" sent in my TLS1.2 capture either.

My question is, is there any way can Chrome know a client cert was requested by the server if that request is not sent in the TLS handshake?

Alternatively, is it possible wireshark is lying to me? When I test against, for example: https://client.badssl.com/ which requests Mutual SSL, I see the Certificate Request right after the Server Key Exchange exactly as I should. I noticed in the TLSv1.2 RFC (https://www.rfc-editor.org/rfc/rfc5246) it notes:

"In particular, the certificate and certificate request handshake messages can be large enough to require fragmentation."

But this should be irrelevant to how Wireshark is displaying the TLS info.

Answer 1

There are several Encrypted Handshake Message in the packet capture after the application data. This very likely means that the server itself does not request a client certificate by default but that the certificate is only requested for specific URL.

In this case first a TLS handshake is done without a CertificateRequest. Once the handshake is finished the client sends the HTTP request over the encrypted connection which is the Application Data in the packet capture. The server will determine that the requested URL needs a client certificate and initiate a renegotiation, i.e. another TLS handshake but this time with a CertificateRequest. But since the connection is already encrypted this renegotiation is only visible as Encrypted Handshake Message and the details cannot be seen without decrypting the traffic.