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
