Thanks everyone. Good to know that Java 18 will have password-less
keystore, so we can support this for other formats too in future. Looks
like we are in agreement that it is reasonable to relax the requirement for
PEM files now.
Regards,
Rajini
On Thu, Mar 24, 2022 at 2:41 PM David Jacot
wrote
Hi all,
Thanks Dejan for bringing this up. Relaxing this constraint seems
reasonable to me. I guess we would have to relax it for the keystores
at some point in the future as well (with Java 18).
Let's wait a few days to see what others think about this.
Best,
David
On Wed, Mar 23, 2022 at 8:46
Hi Rajini,
On Mon, Mar 21, 2022 at 10:02 AM Rajini Sivaram
wrote:
> For the background on the current implementation: We use Java's keystore
> loading for JKS/PKCS12 keystore files and these files require passwords. We
>
In Java 18:
"Passwordless keystores (a keystore with no password required
just a clarification on the part "... we are not left with any choice but
to use the file based config .." - That is "if" we want material rotations
to be picked up automatically.
On Tue, Mar 22, 2022 at 1:57 PM Maulin Vasavada
wrote:
> Hi Dejan and Rajini
>
> I tend to agree with both the argum
Hi Dejan and Rajini
I tend to agree with both the arguments when I read them in isolation :)
However, what I feel is - we have to also take an operator's view of this
setup. If we have encrypted keys/certs already it may be easier to fit with
file based material but if we don't have material encry
For the background on the current implementation: We use Java's keystore
loading for JKS/PKCS12 keystore files and these files require passwords. We
retained the same requirement for PEM files as well for consistency, even
though it is not a language restriction anymore. When PEM keys are provided
Regarding this KIP, we've created an MR that removes the need for
specifying *keyPassword *when PEM certificates and private key are provided
as files: https://github.com/apache/kafka/pull/11916
We think that Kafka should not enforce the use of passwords on private
keys. It would be sufficient to
Looks great Rajini. Indeed PEM is a standard needed to be supported in a
first class way on Kafka.
On Wed, Aug 5, 2020 at 9:55 PM Manikumar wrote:
> Thanks for the KIP. LGTM.
>
> On Wed, Aug 5, 2020 at 3:43 AM Ron Dagostino wrote:
>
> > Yes, Rajinit, it looks good -- an excellently-written KIP.
Hi Andrew, Ron & Manikumar,
Thanks for reviewing the KIP!
If there are no concerns, I will start vote later today.
Regards,
Rajini
On Thu, Aug 6, 2020 at 5:55 AM Manikumar wrote:
> Thanks for the KIP. LGTM.
>
> On Wed, Aug 5, 2020 at 3:43 AM Ron Dagostino wrote:
>
> > Yes, Rajinit, it loo
Thanks for the KIP. LGTM.
On Wed, Aug 5, 2020 at 3:43 AM Ron Dagostino wrote:
> Yes, Rajinit, it looks good -- an excellently-written KIP. Thanks!
>
> Ron
>
> On Mon, Aug 3, 2020 at 9:17 AM Andrew Otto wrote:
>
> > Yes please! I had to build custom tooling to automate generation and
> > distr
Yes, Rajinit, it looks good -- an excellently-written KIP. Thanks!
Ron
On Mon, Aug 3, 2020 at 9:17 AM Andrew Otto wrote:
> Yes please! I had to build custom tooling to automate generation and
> distribution of java truststore and keystore files at Wikimedia for Kafka
> brokers and clients. P
Yes please! I had to build custom tooling to automate generation and
distribution of java truststore and keystore files at Wikimedia for Kafka
brokers and clients. PEM is much more standard outside of the Java world
and it would be simpler to not have to maintain custom tooling for
keystores.
-
Hi all,
I have submitted KIP-651 to support PEM format for SSL key and trust stores:
-
https://cwiki.apache.org/confluence/display/KAFKA/KIP-651+-+Support+PEM+format+for+SSL+certificates+and+private+key
This enables better integration with other Kafka features like dynamic
config update a
13 matches
Mail list logo