Ah, that makes sense. After adding the truststore to the server configs things seem to work correctly, thanks!
marko > Have you configured a truststore in server.properties? You don't need this > when using security.inter.broker.protocol=PLAINTEXT and client-auth is > disabled, but you do need to set truststore for the client-mode > connections > made by the broker when security.inter.broker.protocol=SSL. If that still > doesn't help, running the broker the JVM option -Djavax.net.debug=ssl > would > give more debug info. > > On Wed, Apr 20, 2016 at 11:15 PM, <ma...@kafkatool.com> wrote: > >> After making the suggested change, I see this error during startup >> >> [2016-04-20 18:03:10,522] INFO [Kafka Server 0], started >> (kafka.server.KafkaServer) >> [2016-04-20 18:03:11,093] WARN Failed to send SSL Close message >> (org.apache.kafka.common.network.SslTransportLayer) >> java.io.IOException: Broken pipe >> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) >> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) >> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) >> at sun.nio.ch.IOUtil.write(IOUtil.java:65) >> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) >> at >> >> org.apache.kafka.common.network.SslTransportLayer.flush(SslTransportLayer.java:194) >> at >> >> org.apache.kafka.common.network.SslTransportLayer.close(SslTransportLayer.java:161) >> at >> org.apache.kafka.common.network.KafkaChannel.close(KafkaChannel.java:50) >> at org.apache.kafka.common.network.Selector.close(Selector.java:442) >> at org.apache.kafka.common.network.Selector.poll(Selector.java:310) >> at >> org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:270) >> at >> >> kafka.utils.NetworkClientBlockingOps$.recurse$1(NetworkClientBlockingOps.scala:128) >> at >> >> kafka.utils.NetworkClientBlockingOps$.kafka$utils$NetworkClientBlockingOps$$pollUntilFound$extension(NetworkClientBlockingOps.scala:139) >> at >> >> kafka.utils.NetworkClientBlockingOps$.kafka$utils$NetworkClientBlockingOps$$pollUntil$extension(NetworkClientBlockingOps.scala:105) >> at >> >> kafka.utils.NetworkClientBlockingOps$.blockingReady$extension(NetworkClientBlockingOps.scala:58) >> at >> >> kafka.controller.RequestSendThread.brokerReady(ControllerChannelManager.scala:225) >> at >> >> kafka.controller.RequestSendThread.liftedTree1$1(ControllerChannelManager.scala:172) >> at >> >> kafka.controller.RequestSendThread.doWork(ControllerChannelManager.scala:171) >> at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:63) >> >> and also errors during shutdown >> >> [2016-04-20 18:09:15,293] INFO [Kafka Server 0], Starting controlled >> shutdown (kafka.server.KafkaServer) >> [2016-04-20 18:09:15,330] WARN [Kafka Server 0], Error during controlled >> shutdown, possibly because leader movement took longer than the >> configured >> socket.timeout.ms: Connection to Node(0, debian, 9094) failed >> (kafka.server.KafkaServer) >> >> the relevant configs are >> >> >> listeners=SSL://:9094 >> security.inter.broker.protocol=SSL >> port=9094 >> >> Marko >> >> > If your only listener is SSL, you should set >> > security.inter.broker.protocol >> > to SSL even for single-broker cluster since it is used by the >> controller. >> > I >> > would have expected an error in the logs though if this was not >> configured >> > correctly. >> > >> > On Wed, Apr 20, 2016 at 1:34 AM, <ma...@kafkatool.com> wrote: >> > >> >> There is only one broker in this case. There are no errors (besides >> the >> >> warning below) on either the broker or the client side. It just >> returns >> >> an >> >> empty topic list if plaintext is not configured, even though client >> is >> >> using SSL in both cases. >> >> >> >> marko >> >> >> >> > Hi, >> >> > >> >> > That warning is harmless. Personally, I think it may be a good idea >> to >> >> > remove as it confuses people in cases such as this. >> >> > >> >> > Do you have multiple brokers? Are the brokers configured to use SSL >> >> for >> >> > inter-broker communication (security.inter.broker.protocol)? This >> is >> >> > required if the only listener is for SSL. >> >> > >> >> > Ismael >> >> > >> >> > On Wed, Apr 20, 2016 at 12:42 AM, <ma...@kafkatool.com> wrote: >> >> > >> >> >> What is the correct way of using SSL between the client and >> brokers >> >> if >> >> >> client certificates are not used? The broker (0.9.0.0) reports the >> >> >> following in the log >> >> >> >> >> >> WARN SSL peer is not authenticated, returning ANONYMOUS instead >> >> >> >> >> >> as a result of this (I belive) KafkaConsumer.listTopics() returns >> an >> >> >> empty >> >> >> map. Does this require a custom Authenticator on the broker side? >> If >> >> so, >> >> >> are there examples on how to do that? >> >> >> >> >> >> Interestingly enough, modifying (no other changes) >> >> >> >> >> >> listeners=SSL://:9094 >> >> >> >> >> >> to >> >> >> >> >> >> listeners=PLAINTEXT://:9093,SSL://:9094 >> >> >> >> >> >> makes the listTopics() method to return the topics. If SSL is used >> by >> >> >> the >> >> >> consumer in both cases, I'm not sure why having the plaintext port >> >> would >> >> >> affect the SSL behavior. >> >> >> >> >> >> -- >> >> >> Best regards, >> >> >> Marko >> >> >> www.kafkatool.com >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> > >> > -- >> > Regards, >> > >> > Rajini >> > >> >> >> > > > -- > Regards, > > Rajini >
