Bryan, Stewart Raised NIFI-3794 to track this improvement request
On Thu, May 4, 2017 at 7:38 AM, Bryan Bende <[email protected]> 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 > <[email protected]> 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:[email protected]] > > Sent: Tuesday, April 04, 2017 2:06 PM > > To: [email protected] > > 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 <[email protected]> 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 > >> <[email protected]> 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 > >>> > >>> > >>> >
