[
https://issues.apache.org/jira/browse/KAFKA-10666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286602#comment-17286602
]
Jason commented on KAFKA-10666:
-------------------------------
Hey, sorry I didn't see the reply. This bug is related to decrypting the
keystore files containing TLS certificates related to named listeners, not
authentication of clients.
> Kafka doesn't use keystore / key / truststore passwords for named SSL
> connections
> ---------------------------------------------------------------------------------
>
> Key: KAFKA-10666
> URL: https://issues.apache.org/jira/browse/KAFKA-10666
> Project: Kafka
> Issue Type: Bug
> Components: admin
> Affects Versions: 2.5.0, 2.6.0
> Environment: kafka in an openjdk-11 docker container, the client java
> application is in an alpine container. zookeeper in a separate container.
> Reporter: Jason
> Priority: Minor
>
> When configuring named listener SSL connections with ssl key and keystore
> with passwords including listener.name.ourname.ssl.key.password,
> listener.name.ourname.ssl.keystore.password, and
> listener.name.ourname.ssl.truststore.password via via the AdminClient the
> settings are not used and the setting is not accepted if the default
> ssl.key.password or ssl.keystore.password are not set. We configure all
> keystore and truststore values for the named listener in a single batch using
> incrementalAlterConfigs. Additionally, when ssl.keystore.password is set to
> the value of our keystore password the keystore is loaded for SSL
> communication without issue, however if ssl.keystore.password is incorrect
> and listener.name.ourname.keystore.password is correct, we are unable to load
> the keystore with bad password errors. It appears that only the default
> ssl.xxx.password settings are used. This setting is immutable as when we
> attempt to set it we get an error indicating that the listener.name. setting
> can be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)