I like the initiative, as long as it is backward compatible. Nathan, the patch attached for ZOOKEEPER-2643 <https://issues.apache.org/jira/browse/ZOOKEEPER-2643> is very old (also missing documentation / tests). Would you like to contribute a new PR against our current master branch? Do we consider both Quorum SSL and Client SSL here?
Best regards, Mate On Tue, Oct 13, 2020 at 1:42 AM Nathan Gough <thena...@gmail.com> wrote: > Is there no great way of doing this? Seems like it would solve a lot of > problems for us: providing the context rather than key/truststore paths and > properties will work a lot more cleanly. > > Cheers! > Nathan > > On Wed, Oct 7, 2020 at 5:22 PM Nathan Gough <thena...@gmail.com> wrote: > > > Hi Enrico, > > > > Yes, the goal is to be strict about what protocols and ciphers to allow. > > We have an SSLContext factory we use consistently across NiFi to provide > a > > better security guarantee. > > > > On Wed, Oct 7, 2020 at 5:13 PM Enrico Olivelli <eolive...@gmail.com> > > wrote: > > > >> Nathan, > >> > >> Il Mer 7 Ott 2020, 23:06 Nathan Gough <thena...@gmail.com> ha scritto: > >> > >> > Hi, > >> > > >> > I develop for Apache NiFi and was working on adding TLS to one of our > >> > clients that use Zookeeper. I was wondering if it's possible to > inject a > >> > custom SSLContext similar in concept to this ticket: > >> > > >> > https://issues.apache.org/jira/browse/ZOOKEEPER-2643 > >> > > >> > I can't see a way to provide this through the ZooKeeperAdmin > interface. > >> > > >> > >> Why do you need to inject a custom SSLContext? Can you explain a little > >> more? Is it about limiting ciphers or protocols.... > >> > >> Enrico > >> > >> > >> > Thanks! > >> > Nathan > >> > > >> > > >
