None of the above. If you don't specify ssl.keymanager.algorithm
(see SslConfigs:96) then it uses the JVM default (see SslEngineBuilder:138), which is probably going to be SunX509
(the only standard name is PKIX
, but there's no indication of what that does differently; see Standard Algorithm Names ยง KeyManagerFactory algorithms). Despite the description of the standard algorithm, RFC 3280 does not specify a key selection process per se. However, the actual implemention simply selects some key of one of the desired types for which the corresponding certificate's certification path contains one of the desired issuers (see call chain starting at SunX509KeyManagerImpl.chooseClientAlias).
So the client's choice of key alias is going to be dictated by the certificate issuers that the server says it trusts and the types of keys that the server says it accepts (this is almost always RSA today, but may be different in the future or in specific scenarios). If you have just 1 RSA key issued by a CA that the server trusts, then that's the key it will pick. If 0, then the connection will fail, and if 2 or more, you don't know which one will be picked. In particular, having an expired and unexpired cert that both match the criteria is a recipe for trouble.
I found some interesting details on KeyManager
s and KeyStore
s on a terse systems blog post, but some of the customization they talk about won't be possible without patching Kafka itself. If you need to control key selection with more precision, you'll probably have to implement your own KeyManager or use a third-party one that meets your needs.