You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Stewart Thomas J <St...@JohnDeere.com> on 2017/05/03 21:13:31 UTC
RE: StandardSSLContextService - TLS Client Authentication
Hello - thank you so much for filing that JIRA and it appears to be included in 1.2.0. One question, can we also add the same to ListenRELP processor?
Thanks,
Tom
-----Original Message-----
From: Bryan Bende [mailto:bbende@gmail.com]
Sent: Tuesday, April 04, 2017 2:06 PM
To: users@nifi.apache.org
Subject: Re: StandardSSLContextService - TLS Client Authentication
Created this JIRA: https://issues.apache.org/jira/browse/NIFI-3670
Thanks,
Bryan
On Tue, Apr 4, 2017 at 2:39 PM, Bryan Bende <bb...@gmail.com> wrote:
> Hi Tom,
>
> It looks like ListenSyslog does unfortunately have the client auth
> hard-coded as required:
>
> sslContext = sslContextService.createSSLContext(SSLContextService.ClientAuth.REQUIRED);
>
> The good news is ListenSyslog is really just a combination of
> ListenTCP/ListenUDP + ParseSyslog, and ListenTCP exposes a Client Auth
> property for the user to select WANT, REQUIRED, or NONE.
>
> So you should be able to use ListenTCP + ParseSyslog (if you were
> parsing messages) and set Client Auth to NONE. Let us know if that
> doesn't work.
>
> In the meantime I will create a JIRA to expose the same option for ListenSyslog.
>
> -Bryan
>
>
> On Tue, Apr 4, 2017 at 1:57 PM, Stewart Thomas J
> <St...@johndeere.com> wrote:
>> I have set up two TLS end points in NiFi 1.1.2.
>>
>> ListenHTTP
>> Uses StandardSSLContextService with just a JKS Keystore file. This allows
>> my HTTPS client (curl) to connect to this end point and upload files.
>>
>> ListenSyslog
>> Configured with StandardSSLContextService containing a JKS Keystore and a
>> JKS Truststore (contains my CA).
>>
>>
>> Where I am running into trouble is with my ListenSyslog. When I configure a
>> CentOS7 client (rsyslog) to use TLS pointing to my ListenSyslog, I am
>> getting an error on the NiFi side:
>>
>> 2017-04-04 12:50:30,839 ERROR [pool-86823-thread-1]
>> o.a.n.r.io.socket.ssl.SSLSocketChannel
>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel@21e44b13 Failed to
>> connect due to {}
>> javax.net.ssl.SSLHandshakeException: null cert chain
>> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
>> ~[na:1.8.0_92]
>> at
>> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>> ~[na:1.8.0_92]
>> at
>> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
>> ~[na:1.8.0_92]
>> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
>> ~[na:1.8.0_92]
>> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) ~[na:1.8.0_92]
>> at
>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.performHandshake(SSLSocketChannel.java:205)
>> [nifi-security-utils-1.1.2.jar:1.1.2]
>> at
>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.connect(SSLSocketChannel.java:158)
>> [nifi-security-utils-1.1.2.jar:1.1.2]
>> at
>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.read(SSLSocketChannel.java:540)
>> [nifi-security-utils-1.1.2.jar:1.1.2]
>> at
>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.read(SSLSocketChannel.java:533)
>> [nifi-security-utils-1.1.2.jar:1.1.2]
>> at
>> org.apache.nifi.processor.util.listen.handler.socket.SSLSocketChannelHandler.run(SSLSocketChannelHandler.java:76)
>> [nifi-processor-utils-1.1.2.jar:1.1.2]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> [na:1.8.0_92]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> [na:1.8.0_92]
>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
>>
>>
>> This is using the following configuration for rsyslog client.
>>
>> $DefaultNetStreamDriver gtls # use gtls netstream driver
>> $DefaultNetstreamDriverCAFile /usr/local/hadoop/keys/myCA.pem
>> $ActionSendStreamDriverMode 1 # Require TLS for the connection
>> $ActionSendStreamDriverAuthMode anon # Server is NOT authenticated
>> *.* @@syslog.host.com:514;RSYSLOG_SyslogProtocol23Format
>>
>> If I create client certs and add this to rsyslog client, then it works to
>> talk to ListenSyslog:
>> $DefaultNetstreamDriverCertFile /etc/syslog.d/keys/syslog.crt
>> $DefaultNetstreamDriverKeyFile /etc/syslog.d/keys/syslog.key
>>
>> My question is, does ListenSyslog with StandardSSLContextService force
>> client certificates? I was trying to see if we could set this up without
>> managing client certs (just encrypt the data traffic like I was able to do
>> with ListenHTTP).
>>
>> Thanks,
>> Tom
>>
>>
>>
Re: StandardSSLContextService - TLS Client Authentication
Posted by Andre <an...@fucs.org>.
Bryan, Stewart
Raised NIFI-3794 to track this improvement request
On Thu, May 4, 2017 at 7:38 AM, Bryan Bende <bb...@gmail.com> wrote:
> Yes, we should address ListenRELP, but it will need to be a separate
> ticket for a future release, since release efforts are already under
> way for 1.2.0.
>
> Can you create another JIRA just like the other, but for ListenRELP?
>
> What we need to do is push the SSLContextService and Client Auth down
> to the common base class that ListenRELP and ListenTCP extend from so
> that they don't provide different options like this. There was a valid
> reason why it was previously done separately, but it no longer
> applies.
>
> Thanks,
>
> Bryan
>
>
>
> On Wed, May 3, 2017 at 5:13 PM, Stewart Thomas J
> <St...@johndeere.com> wrote:
> > Hello - thank you so much for filing that JIRA and it appears to be
> included in 1.2.0. One question, can we also add the same to ListenRELP
> processor?
> >
> > Thanks,
> > Tom
> >
> > -----Original Message-----
> > From: Bryan Bende [mailto:bbende@gmail.com]
> > Sent: Tuesday, April 04, 2017 2:06 PM
> > To: users@nifi.apache.org
> > Subject: Re: StandardSSLContextService - TLS Client Authentication
> >
> > Created this JIRA: https://issues.apache.org/jira/browse/NIFI-3670
> >
> > Thanks,
> >
> > Bryan
> >
> > On Tue, Apr 4, 2017 at 2:39 PM, Bryan Bende <bb...@gmail.com> wrote:
> >> Hi Tom,
> >>
> >> It looks like ListenSyslog does unfortunately have the client auth
> >> hard-coded as required:
> >>
> >> sslContext = sslContextService.createSSLContext(
> SSLContextService.ClientAuth.REQUIRED);
> >>
> >> The good news is ListenSyslog is really just a combination of
> >> ListenTCP/ListenUDP + ParseSyslog, and ListenTCP exposes a Client Auth
> >> property for the user to select WANT, REQUIRED, or NONE.
> >>
> >> So you should be able to use ListenTCP + ParseSyslog (if you were
> >> parsing messages) and set Client Auth to NONE. Let us know if that
> >> doesn't work.
> >>
> >> In the meantime I will create a JIRA to expose the same option for
> ListenSyslog.
> >>
> >> -Bryan
> >>
> >>
> >> On Tue, Apr 4, 2017 at 1:57 PM, Stewart Thomas J
> >> <St...@johndeere.com> wrote:
> >>> I have set up two TLS end points in NiFi 1.1.2.
> >>>
> >>> ListenHTTP
> >>> Uses StandardSSLContextService with just a JKS Keystore file. This
> allows
> >>> my HTTPS client (curl) to connect to this end point and upload files.
> >>>
> >>> ListenSyslog
> >>> Configured with StandardSSLContextService containing a JKS Keystore
> and a
> >>> JKS Truststore (contains my CA).
> >>>
> >>>
> >>> Where I am running into trouble is with my ListenSyslog. When I
> configure a
> >>> CentOS7 client (rsyslog) to use TLS pointing to my ListenSyslog, I am
> >>> getting an error on the NiFi side:
> >>>
> >>> 2017-04-04 12:50:30,839 ERROR [pool-86823-thread-1]
> >>> o.a.n.r.io.socket.ssl.SSLSocketChannel
> >>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel@21e44b13 Failed
> to
> >>> connect due to {}
> >>> javax.net.ssl.SSLHandshakeException: null cert chain
> >>> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:
> 1431)
> >>> ~[na:1.8.0_92]
> >>> at
> >>> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
> >>> ~[na:1.8.0_92]
> >>> at
> >>> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
> >>> ~[na:1.8.0_92]
> >>> at sun.security.ssl.SSLEngineImpl.wrap(
> SSLEngineImpl.java:1186)
> >>> ~[na:1.8.0_92]
> >>> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
> ~[na:1.8.0_92]
> >>> at
> >>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.
> performHandshake(SSLSocketChannel.java:205)
> >>> [nifi-security-utils-1.1.2.jar:1.1.2]
> >>> at
> >>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.
> connect(SSLSocketChannel.java:158)
> >>> [nifi-security-utils-1.1.2.jar:1.1.2]
> >>> at
> >>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.
> read(SSLSocketChannel.java:540)
> >>> [nifi-security-utils-1.1.2.jar:1.1.2]
> >>> at
> >>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.
> read(SSLSocketChannel.java:533)
> >>> [nifi-security-utils-1.1.2.jar:1.1.2]
> >>> at
> >>> org.apache.nifi.processor.util.listen.handler.socket.
> SSLSocketChannelHandler.run(SSLSocketChannelHandler.java:76)
> >>> [nifi-processor-utils-1.1.2.jar:1.1.2]
> >>> at
> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> >>> [na:1.8.0_92]
> >>> at
> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> >>> [na:1.8.0_92]
> >>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
> >>>
> >>>
> >>> This is using the following configuration for rsyslog client.
> >>>
> >>> $DefaultNetStreamDriver gtls # use gtls netstream driver
> >>> $DefaultNetstreamDriverCAFile /usr/local/hadoop/keys/myCA.pem
> >>> $ActionSendStreamDriverMode 1 # Require TLS for the connection
> >>> $ActionSendStreamDriverAuthMode anon # Server is NOT authenticated
> >>> *.* @@syslog.host.com:514;RSYSLOG_SyslogProtocol23Format
> >>>
> >>> If I create client certs and add this to rsyslog client, then it works
> to
> >>> talk to ListenSyslog:
> >>> $DefaultNetstreamDriverCertFile /etc/syslog.d/keys/syslog.crt
> >>> $DefaultNetstreamDriverKeyFile /etc/syslog.d/keys/syslog.key
> >>>
> >>> My question is, does ListenSyslog with StandardSSLContextService force
> >>> client certificates? I was trying to see if we could set this up
> without
> >>> managing client certs (just encrypt the data traffic like I was able
> to do
> >>> with ListenHTTP).
> >>>
> >>> Thanks,
> >>> Tom
> >>>
> >>>
> >>>
>
Re: StandardSSLContextService - TLS Client Authentication
Posted by Bryan Bende <bb...@gmail.com>.
Yes, we should address ListenRELP, but it will need to be a separate
ticket for a future release, since release efforts are already under
way for 1.2.0.
Can you create another JIRA just like the other, but for ListenRELP?
What we need to do is push the SSLContextService and Client Auth down
to the common base class that ListenRELP and ListenTCP extend from so
that they don't provide different options like this. There was a valid
reason why it was previously done separately, but it no longer
applies.
Thanks,
Bryan
On Wed, May 3, 2017 at 5:13 PM, Stewart Thomas J
<St...@johndeere.com> wrote:
> Hello - thank you so much for filing that JIRA and it appears to be included in 1.2.0. One question, can we also add the same to ListenRELP processor?
>
> Thanks,
> Tom
>
> -----Original Message-----
> From: Bryan Bende [mailto:bbende@gmail.com]
> Sent: Tuesday, April 04, 2017 2:06 PM
> To: users@nifi.apache.org
> Subject: Re: StandardSSLContextService - TLS Client Authentication
>
> Created this JIRA: https://issues.apache.org/jira/browse/NIFI-3670
>
> Thanks,
>
> Bryan
>
> On Tue, Apr 4, 2017 at 2:39 PM, Bryan Bende <bb...@gmail.com> wrote:
>> Hi Tom,
>>
>> It looks like ListenSyslog does unfortunately have the client auth
>> hard-coded as required:
>>
>> sslContext = sslContextService.createSSLContext(SSLContextService.ClientAuth.REQUIRED);
>>
>> The good news is ListenSyslog is really just a combination of
>> ListenTCP/ListenUDP + ParseSyslog, and ListenTCP exposes a Client Auth
>> property for the user to select WANT, REQUIRED, or NONE.
>>
>> So you should be able to use ListenTCP + ParseSyslog (if you were
>> parsing messages) and set Client Auth to NONE. Let us know if that
>> doesn't work.
>>
>> In the meantime I will create a JIRA to expose the same option for ListenSyslog.
>>
>> -Bryan
>>
>>
>> On Tue, Apr 4, 2017 at 1:57 PM, Stewart Thomas J
>> <St...@johndeere.com> wrote:
>>> I have set up two TLS end points in NiFi 1.1.2.
>>>
>>> ListenHTTP
>>> Uses StandardSSLContextService with just a JKS Keystore file. This allows
>>> my HTTPS client (curl) to connect to this end point and upload files.
>>>
>>> ListenSyslog
>>> Configured with StandardSSLContextService containing a JKS Keystore and a
>>> JKS Truststore (contains my CA).
>>>
>>>
>>> Where I am running into trouble is with my ListenSyslog. When I configure a
>>> CentOS7 client (rsyslog) to use TLS pointing to my ListenSyslog, I am
>>> getting an error on the NiFi side:
>>>
>>> 2017-04-04 12:50:30,839 ERROR [pool-86823-thread-1]
>>> o.a.n.r.io.socket.ssl.SSLSocketChannel
>>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel@21e44b13 Failed to
>>> connect due to {}
>>> javax.net.ssl.SSLHandshakeException: null cert chain
>>> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
>>> ~[na:1.8.0_92]
>>> at
>>> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>>> ~[na:1.8.0_92]
>>> at
>>> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
>>> ~[na:1.8.0_92]
>>> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
>>> ~[na:1.8.0_92]
>>> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) ~[na:1.8.0_92]
>>> at
>>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.performHandshake(SSLSocketChannel.java:205)
>>> [nifi-security-utils-1.1.2.jar:1.1.2]
>>> at
>>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.connect(SSLSocketChannel.java:158)
>>> [nifi-security-utils-1.1.2.jar:1.1.2]
>>> at
>>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.read(SSLSocketChannel.java:540)
>>> [nifi-security-utils-1.1.2.jar:1.1.2]
>>> at
>>> org.apache.nifi.remote.io.socket.ssl.SSLSocketChannel.read(SSLSocketChannel.java:533)
>>> [nifi-security-utils-1.1.2.jar:1.1.2]
>>> at
>>> org.apache.nifi.processor.util.listen.handler.socket.SSLSocketChannelHandler.run(SSLSocketChannelHandler.java:76)
>>> [nifi-processor-utils-1.1.2.jar:1.1.2]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> [na:1.8.0_92]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>> [na:1.8.0_92]
>>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92]
>>>
>>>
>>> This is using the following configuration for rsyslog client.
>>>
>>> $DefaultNetStreamDriver gtls # use gtls netstream driver
>>> $DefaultNetstreamDriverCAFile /usr/local/hadoop/keys/myCA.pem
>>> $ActionSendStreamDriverMode 1 # Require TLS for the connection
>>> $ActionSendStreamDriverAuthMode anon # Server is NOT authenticated
>>> *.* @@syslog.host.com:514;RSYSLOG_SyslogProtocol23Format
>>>
>>> If I create client certs and add this to rsyslog client, then it works to
>>> talk to ListenSyslog:
>>> $DefaultNetstreamDriverCertFile /etc/syslog.d/keys/syslog.crt
>>> $DefaultNetstreamDriverKeyFile /etc/syslog.d/keys/syslog.key
>>>
>>> My question is, does ListenSyslog with StandardSSLContextService force
>>> client certificates? I was trying to see if we could set this up without
>>> managing client certs (just encrypt the data traffic like I was able to do
>>> with ListenHTTP).
>>>
>>> Thanks,
>>> Tom
>>>
>>>
>>>