nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre <andre-li...@fucs.org>
Subject Re: StandardSSLContextService - TLS Client Authentication
Date Wed, 03 May 2017 22:03:58 GMT
Bryan, Stewart

Raised NIFI-3794 to track this improvement request

On Thu, May 4, 2017 at 7:38 AM, Bryan Bende <bbende@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
> <StewartThomasJ@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 <bbende@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
> >> <StewartThomasJ@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
> >>>
> >>>
> >>>
>

Mime
View raw message