You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Michael Di Domenico <md...@gmail.com> on 2020/10/14 18:34:12 UTC
sslcontext certs
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
Re: [EXT] sslcontext certs
Posted by Andy LoPresto <al...@apache.org>.
The flow.xml.gz file which defines the flow does contain these paths. You could automate the flow change via Puppet (keeping in mind that other values will change as you modify NiFi flows via the canvas), or you could define these values as parameters [1] within NiFi and have each of the components reference those parameters in the path properties.
[1] https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#Parameters
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
He/Him
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Oct 15, 2020, at 7:45 AM, Michael Di Domenico <md...@gmail.com> wrote:
>
> On Wed, Oct 14, 2020 at 3:59 PM Nathan Gough <th...@gmail.com> wrote:
>>
>> 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?
>
> Possibly. Its likely the sslcontext documentation wasn't clear when i
> read it and didn't realize i could do this.
>
> and yes i came to same conclusion about symlinking the keystores on
> the local filesystem, which should also work.
>
> ideally, these parameters would be managed via some xml file that i
> could have puppet control. so when the certs change, puppet can push
> out the changes and update everything. yes i can do this with a
> symlink, but it's not my preferred method to declare the resources and
> changes.
Re: [EXT] Re: sslcontext certs
Posted by Michael Di Domenico <md...@gmail.com>.
On Wed, Oct 14, 2020 at 3:59 PM Nathan Gough <th...@gmail.com> wrote:
>
> 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?
Possibly. Its likely the sslcontext documentation wasn't clear when i
read it and didn't realize i could do this.
and yes i came to same conclusion about symlinking the keystores on
the local filesystem, which should also work.
ideally, these parameters would be managed via some xml file that i
could have puppet control. so when the certs change, puppet can push
out the changes and update everything. yes i can do this with a
symlink, but it's not my preferred method to declare the resources and
changes.
Re: [EXT] Re: sslcontext certs
Posted by "Peter Wicks (pwicks)" <pw...@micron.com>.
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 <th...@gmail.com>
Reply-To: "users@nifi.apache.org" <us...@nifi.apache.org>
Date: Wednesday, October 14, 2020 at 1:59 PM
To: "users@nifi.apache.org" <us...@nifi.apache.org>
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) <pw...@micron.com>> 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" <md...@gmail.com>> 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 <jo...@gmail.com>> 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 <md...@gmail.com>> 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
Re: [EXT] Re: sslcontext certs
Posted by Nathan Gough <th...@gmail.com>.
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) <pw...@micron.com>
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" <md...@gmail.com>
> 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 <jo...@gmail.com> 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 <
> mdidomenico4@gmail.com> 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
>
Re: [EXT] Re: sslcontext certs
Posted by "Peter Wicks (pwicks)" <pw...@micron.com>.
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" <md...@gmail.com> 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 <jo...@gmail.com> 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 <md...@gmail.com> 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
Re: sslcontext certs
Posted by Michael Di Domenico <md...@gmail.com>.
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 <jo...@gmail.com> 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 <md...@gmail.com> 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
Re: sslcontext certs
Posted by Joe Witt <jo...@gmail.com>.
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 <md...@gmail.com>
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
>