Micron Confidential I agree Nathan. I believe the situation I ran into came about due to bad planning. Users started independently hosting services, and it was only later that we realized that a centralized service or variables would be a better solution.
It would probably be easier to just go the direction you suggested 😊 From: Nathan Gough <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, October 14, 2020 at 1:59 PM To: "[email protected]" <[email protected]> Subject: Re: [EXT] Re: sslcontext certs 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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 Micron Confidential
