nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stewart Thomas J <StewartThom...@JohnDeere.com>
Subject RE: StandardSSLContextService - TLS Client Authentication
Date Tue, 04 Apr 2017 20:24:42 GMT
Worked great. Thanks! 

-Tom

-----Original Message-----
From: Bryan Bende [mailto:bbende@gmail.com] 
Sent: Tuesday, April 04, 2017 2:06 PM
To: users@nifi.apache.org
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 <bbende@gmail.com> 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
> <StewartThomasJ@johndeere.com> 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
>>
>>
>>
Mime
View raw message