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