It should be like this, in case only the brokers need to authenticate (one-way server side SSL auth) to the clients: You need: 1. Client side: 1 keystore (client.truststore.jks) containing just the ca_cert you created and was used to sign the broker / server certificates 2. Server side: On each broker 1 keystore (server.keystore.jks) containing both the server specific certificate generated before, ( which should now be signed by the CA) and the certificate of the CA itself. What is misleading in the Kafka documentation is the first step, where a keystore 'server.keystore.jks' is created in the very first step, only to export the unsigned cert from to actually sign it. This is not the same 'server.keystore.jks' as in 2. above as the it should not contain the unsigned broker cert anymore ! You don't necessarily need a keystore to create a certificate to sign, you can also just create a cert + key, have it signed and then import it into a new keystore. Also, it makes more sense to me to copy the CA cert onto the brokers then moving it back-and-forth from server -> CA node (to sign) -> back to server (to import into final 'server.keystore.jks') Hope it makes sense ... View more

@Shailendra Lohia And yes, you could use the same group ID for many different topics, if you want. For Kafka that would be transparent, as it would just be totally different 'keys' (topic:consumer_group_id) to Kafka ... View more

Hi Shailendra, Having 2 Kafka consumers with the same group ID will be just fine. This is by design actually. Kafka internals will try to load balance the topic consumption between any consumers registering on the group ID. The number of consumers per group ID is not bound to anything, you can have as many as you want. Usually the consuming application (like Storm) sets/decides this. For optimal performance you would typically have as many consumers registering for a group ID as there are topic partitions. That way, a consumer would not have to switch between multiple assigned partitions, but would just stick to consuming from the same partition during its life span, which is most efficient. ... View more

@msumbul Please mark the question as answered if sufficiently answered ... View more

@msumbul Please mark the question as answered if sufficiently answered ... View more

@asubramanian This is not possible since Rest and Mgt. UI are both not installed as OS level services before HCP1.2.1.0. ... View more

@Frank Kam (Maybe you can create a separate topic for your problem as I think it is quite different from the original question.) Did you create the USERS and AUTHORITIES table on your chosen SQL platform? Did you insert the designated user data in those tables for the user you expect to log on with? ... View more

@Vedant Jain Very interesting article. And usefull I am looking for a way though to do to same for NewConsumers that store their offset in the topic __consumer_offsets. Do you know how to manage that offset? ... View more