In general Kafka makes an effort to be langauge-neutral so that Kafka clients can be implemented on platforms other than Java. For example, we have things like librdkafka which allow people to access Kafka from C or Python. Unless I'm misunderstanding something, giving direct access to the SSLContext and SSLSocketFactory seems like it would make that kind of compatibility harder, if it were even still possible. I'm curious if there's a way to do this by adding configuration entries for what you need?
best, Colin On Mon, Oct 15, 2018, at 13:20, Pellerin, Clement wrote: > I am new to this mailing list. I am not sure what I should do next. > Should I create a KIP to discuss this? > > -----Original Message----- > From: Pellerin, Clement > Sent: Wednesday, October 10, 2018 4:38 PM > To: dev@kafka.apache.org > Subject: KAFKA-6654 custom SSLContext > > KAFKA-6654 correctly states that there will never be enough > configuration parameters to fully configure the SSLContext/ > SSLSocketFactory created by Kafka. > For example, in our case, we need an alias to choose the key in the > keystore, and we need an implementation of OCSP. > KAFKA-6654 suggests to make the creation of the SSLContext a pluggable > implementation. > Maybe by declaring an interface and passing the name of an > implementation class in a new parameter. > > Many libraries solve this problem by accepting the SSLContextFactory > instance from the application. > How about passing the instance as the value of a runtime configuration > parameter? > If that parameter is set, all other ssl.* parameters would be ignored. > Obviously, this parameter could only be set programmatically. > > I would like to hear the proposed solution by the Kafka maintainers. > > I can help implementing a patch if there is an agreement on the desired > solution.
