Hi Roman
I think the problem is the SSL ServerHello is not sending back to the client the DN of the CA Certificates that issued your client certificate - when asking for a client cert the usual protocol is that the ServerHello replies with a list of distinguished names of issuers that the server will accept.
Now the client program (Chrome) in your case then looks to see if it has any client certs that match any of those issuers, and then pops up a dialog to let you choose which one. Some programs use that DN list to auto select which client cert to send back as well.
That's the normal process, and what I expect is happening with Chrome. But different client programs do different things, the list is not enforceable on the client side and some programs (PostMan is one example) totally ignores that list of DN's and lets you specify a cert based on the target URL and sends that.
Chrome and other browsers are more normal and use the DN list to filter which certs to allow you to pick from that popup list.
Step 1:
But before we go there - lets check if the TCP listenr is setup to either option/required for "Client Authentication" - most likely it will be:
Step 2:
Do you have the CA certificate that issued/signed your client cert request ?
If you can look at the list of Trusted Certificates, the DN list and that have "Sign Client" as usage will be sent to the client in the ServerHello.
So if you can load the cert that issued your client certificate, make sure you check the ""Sign Client"" usage option. Then it should be sent back in the allowable client cert DN lists. You can have multiple certs marked for "Sign Client" and all their DN's will be sent in he ServerHello. You can also have no certs marked - but results of that vary depending on the client program.
At the network layer if you log the SSL handshake (either via wireshark or in java via that -Djava.net.debug=all setting. You can view the ServerHello returned and it will be something like this :
*** CertificateRequest
Cert Types: RSA, DSS, ECDSACert Authorities:
<CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US>
<CN=*.app.prod.e1.dev.ca.com, O="Broadcom, Inc.", L=San Jose, ST=California, C=US>
Here, client certs issued by those two issuer DN's are allowed.
(and ok yes the issuer names there don't look like they should be signing client certs - but they were real ones from a test case :-)
There was also an interesting case recently where when the "acceptable" DN list returned was empty it would allow any client cert to be selected, but if there were any entries in the DN list - it would restrict the chosen cert to those from that DN list; Client suddenly stops sending client certificate t - CA Knowledge
Hope that helps.
Cheers - Mark