Hi Boyang, I think that it would improve the ergonomics of dealing with short lived certificates to have this be the default behaviour.
It should be noted that transparently reloading certificates and keys when they changed on disk can be implemented right now registering a custom KeyManagerFactory, but to say that the JDK is designed to make this easy would be an overstatement. The things that we do to get this working: 1. Create a class implementing SecurityProviderCreator that will return a Provider that registers a custom KeyManagerFactory implementation. 2. This custom KeyManagerFactory would return KeyManager instances that implements X509ExendedKeyManager 3. The custom KeyManager would return cached but up to date values for the getCertificateChain() and getPrivateKey() methods. 5. Configure Kafka with security.providers referencing the class defined in 1) This is not something I would wish upon anyone, but it works. Solving this for everyone inside Apache Kafka seems like a much preferred solution. Cheers noa ps. It seems my apple.com <http://apple.com/> email address ends up on the list as apple.com <http://apple.com/>.INVALID. Is this a known problem? For now I’m working around it by using my personal email. > On 4 Dec 2020, at 01:28, Boyang Chen <reluctanthero...@gmail.com> wrote: > > Hey there, > > I would like to start the discussion thread for KIP-687: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-687%3A+Automatic+Reloading+of+Security+Store > > This KIP is trying to deprecate the AlterConfigs API support of updating > the security store by reloading path in-place, and replace with a > file-watch mechanism inside the broker. Let me know what you think. > > Best, > Boyang
