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 >>> >>> >>>
