Hi Kondrát, Thanks for the KIP. I took a look and the use case does make sense - even within private CA certs, the policy seems to be to move away from issuing both client and server webAuth EKUs. And the inter-broker roles do present a real scenario that can pose a challenge currently.
However, AK1. The proliferation of the SSL configs essentially 2x for client config seems like overkill to me. JCA is already notorious for the myriad of config options I have to set and the keytool/openssl tools makes my head spin usually. So, I think looking for a solution with fewer knobs to tweak might make it more digestible for me. AK2. The SSL config values are in the common clients module reused between all clients/admin/broker alike. So if we introduce ssl.client.*, then you’re going to cause some confusion for producer/consumer clients which are essentially just client EKUs. AK3. I realise you’re tweaking the configs because the DefaultSSLEngineFactory reads these params and yes it makes sense to create new props to do something different. But I think you’re on the right but parallel track to the solution. KIP-519 introduced an ssl.engine.factory.class that will implement all the hooks that you need. So, I think you can implement a custom ssl engine factory that can initialise a different SSLEngine for createClientSslEngine and createServerSslEngine by reading different key material and different SSLContexts. You can even extend DefaultSSLEngineFactory since it’s in the public contract. WDYT? AK4. If you did want to reuse the default SSL Engine Factory, I think the alternative rejected you listed shouldn’t be overlooked. What’s wrong with using multiple certificates with a plain JKS? It was the principal intention to store multiple key material as a bag of secrets each with its alias, password, and certificates. I think that property makes the KIP much more doable because now you can just tweak the default factory and point to a different alias for the client and server roles. It’s just 2 configs as opposed to 10 more. LMK your thoughts. Thanks, Aditya Kousik > On Jul 29, 2026, at 08:57, Kondrát Bertalan <[email protected]> wrote: > > Hi, > I’d like to start a discussion on a KIP to improve public Certificate > Authorities (CA) compatibility after public CAs are actively deprecating > and will soon stop providing multipurpose certificates. > This presents a breaking operational challenge for Kafka environments > relying on public CAs. A Kafka broker is simultaneously a TLS server (it > accepts connections on its listeners) and a TLS client (it dials other > brokers and controllers). With a single keystore, the same certificate is > presented in both roles. > > https://cwiki.apache.org/confluence/spaces/KAFKA/pages/430408110/KIP-1354+Single+purpose+TLS+extended+key+usages+EKU+support > > Thanks, > Berci
