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