Is there a reason each ListenHTTP has a unique SSLContextService if they're all using the same certificates?
If it were me, I'd use a single shared SSLContextService, and when I needed to update the certificate in the keystore/truststore, I would change it on disk by renaming the old file and putting the new file in place with the original name. Now NiFi and the context service refers to the updated certificates and no NiFi configuration changed. Does this work for you? Nathan On Wed, Oct 14, 2020 at 3:29 PM Peter Wicks (pwicks) <[email protected]> wrote: > Micron Confidential > > I've found this annoying in the past as well. I would not be opposed to an > additional implementation of the SSLContext that uses the NiFi certs by > default, though... if it uses the client certificate as well you'd have to > make it restricted, so as to prevent users from impersonating the servers > identity when communicating with external services. (A restricted > Controller Service?) > > --Peter > > On 10/14/20, 12:44 PM, "Michael Di Domenico" <[email protected]> > wrote: > > ah, okay that sounds like maybe a step in a good direction, but > doesn't necessarily solve my problem. What I'm trying to alleviate is > the need to go into nifi to change the certs when they expire. > > i'll have to look up parameter contexts, that should at least make it > so there's only one place to make the change. > > thanks > > On Wed, Oct 14, 2020 at 2:40 PM Joe Witt <[email protected]> wrote: > > > > Michael, > > > > There is not any specific way supported or intended to combine the > context used by NiFi's own HTTP server with those that would be used by > processors within the flow. > > > > However, using parameter contexts here is a great way to ensure you > have only a single place to update for flow internals. If those values are > parameterized it should work out nicely. > > > > Thanks > > > > On Wed, Oct 14, 2020 at 11:34 AM Michael Di Domenico < > [email protected]> wrote: > >> > >> i have a nifi server with several listenhttp modules on different > >> ports. each one has an sslcontext within it that uses the same > certs > >> as the main 443 instance. > >> > >> sadly i changed the cert when expired on the 443 port, but failed to > >> change the sslcontext on the ports. is there a way to tell the > >> sslcontext on the other ports to just use the same cert that's on > the > >> 443 port? > >> > >> what i'm trying to avoid having to do is change the filename in all > >> the contexts to point to the new cert, i'd rather change it in one > >> place and have everything else pick it up > >> > >> using a symlink on the filesystem seemed like one way, but i thought > >> there might be a way to do it in nifi > > > Micron Confidential >
