Thanks Shawn for your reply. I now managed to get a working example running: https://github.com/rbuffat/kafka_playground/tree/main/kafkasslv3
What I did is to configure docker-compose so that the resulting FQDN is resolvable. Thus having a directory name (and thus the docker-compose project name) without underscores and defining a custom network with explicitly setting a name for it in the docker-compose.yml. This results in that "kafka_ssl_v2-zookeeper-1.kafka_ssl_default2" becomes to "kafkasslv3-zookeeper-1.kafka", which is resolvable. All configuration options are set in the docker-compose.yml[1]. As docker automatically assigns ip addresses to the containers the configuration only uses host-names. It is indeed strange. Especially as it seems to work with kafka (given there is not something misconfigured there at the moment). The reverse DNS is my best guess at the moment. The zookeeper documentations mentions the following[2]: > Please note that the alias (-alias) and the distinguished name (-dname) must match the hostname of the machine that is associated with, otherwise hostname verification won't work. > keytool -genkeypair -alias $(hostname -f) -keyalg RSA -keysize 2048 -dname "cn=$(hostname -f)" -keypass password -keystore keystore.jks -storepass password But this also does not really work for docker containers as to my knowledge docker uses the container ids as hostname which is not known beforehand: $ hostname -f a5ee07583d8b Do you think it would warrant creating an issue in the zookeeper issue tracker? lg rene [1] https://github.com/rbuffat/kafka_playground/blob/main/kafka_ssl_v2/docker-compose.yml [2] https://zookeeper.apache.org/doc/r3.8.0/zookeeperAdmin.html#Quorum+TLS On Thu, 7 Apr 2022 at 06:09, Shawn Heisey <[email protected]> wrote: > On 2022-04-06 14:54, René Buffat wrote: > > javax.net.ssl.SSLPeerUnverifiedException: Certificate for > > <kafka_ssl-zookeeper2-1.kafka_ssl_default> doesn't match common name of > > the > > certificate subject: zookeeper2 > > java.security.cert.CertificateException: Failed to verify both host > > address > > and host name > > Generally speaking, I have never heard of anything SSL-related that > looks at or cares about reverse DNS. > > What should matter is what the CN (or SAN, for certificates that handle > multiple names) is, and what hostname the client is using to connect to > the server. Those have to match. When using SSL, you do not want to > specify an IP address for the host, you want to give it a name, because > it is very unlikely that you'll see an IP address in a certificate > unless you create it with a private CA. > > If reverse DNS is the only place that the longer name appears, then > either the SSL verification is entirely too picky, or you have given the > client an IP address for the server instead of a name, and it is looking > up the reverse DNS so that it has a name to compare to the cert. I have > no idea whether the ZK client (or maybe Java itself) does this, but it > wouldn't surprise me. > > Thanks, > Shawn >
