exporting a template vs Variables vs other settings

[Jean-Sebastien Vachon]

Hi,

When I export/create a template based on my current flow, is there a way to 
extract the current variables/settings at the same time?

Is there a way of setting these settings (max threads)  and variables through 
the nifi.properties (or other configuration file)?

I'm looking to fully automate the creation of a cluster through Terraform and 
that's about the only missing piece.

Thanks

Re: Nifi Registry + Git: target registry ignores git flows

[Bryan Bende]

I'm not totally sure, but there is a good chance this is related to
being on Windows, which technically is not officially supported by
NiFi Registry [1].

The line that logged "WARN [main] org.eclipse.jgit.util.FS_Win32 null"
is concerning and may indicated that the Git provider is not
initialized correctly, but I can't really tell from looking at the
JGit code.

For the flow that is saying not found during start up, does that flow
look correct in the git repo, or is it actually not there?

[1] 
https://nifi.apache.org/docs/nifi-registry-docs/html/administration-guide.html#system-requirements

On Wed, Sep 12, 2018 at 6:40 PM, David Gallagher
 wrote:
> Hi – ok, now I’ve got a different (but maybe related?) problem. I’ve set up
> the nifi registry on a remote server with a git repository. I can add
> process groups from nifi to the registry for version control, and it does
> create the objects as expected in the repository. However, when I try to
> export a flow using the cli tools, I get the following error (in the log
> file):
>
>
>
> 2018-09-12 18:21:55,762 INFO [main] org.apache.nifi.registry.NiFiRegistry
> Registry initialization took 18603838900 nanoseconds (18 seconds).
>
> 2018-09-12 18:22:08,270 INFO [NiFi Registry Web Server-17]
> o.a.n.r.w.m.IllegalStateExceptionMapper java.lang.IllegalStateException:
> Access tokens are only issued over HTTPS. Returning Conflict response.
>
> 2018-09-12 18:24:13,341 ERROR [NiFi Registry Web Server-17]
> o.a.n.r.web.mapper.ThrowableMapper An unexpected error has occurred:
> java.lang.NullPointerException. Returning Internal Server Error response.
>
> java.lang.NullPointerException: null
>
> at
> org.eclipse.jgit.lib.Repository.resolve(Repository.java:526)
> ~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
>
> at
> org.eclipse.jgit.lib.Repository.resolve(Repository.java:487)
> ~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
>
> at
> org.apache.nifi.registry.provider.flow.git.GitFlowMetaData.getContent(GitFlowMetaData.java:422)
> ~[nifi-registry-framework-0.2.0.jar:0.2.0]
>
> at
> org.apache.nifi.registry.provider.flow.git.GitFlowPersistenceProvider.getFlowContent(GitFlowPersistenceProvider.java:180)
> ~[nifi-registry-framework-0.2.0.jar:0.2.0]
>
> at
> org.apache.nifi.registry.service.RegistryService.getVersionedFlowSnapshot(RegistryService.java:688)
> ~[nifi-registry-framework-0.2.0.jar:0.2.0]
>
> at
> org.apache.nifi.registry.service.RegistryService.getFlowSnapshot(RegistryService.java:673)
> ~[nifi-registry-framework-0.2.0.jar:0.2.0]
>
> at
> org.apache.nifi.registry.service.RegistryService$$FastClassBySpringCGLIB$$274de08.invoke()
> ~[nifi-registry-framework-0.2.0.jar:0.2.0]
>
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> ~[spring-core-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:746)
> ~[spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
> ~[spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:294)
> ~[spring-tx-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:98)
> ~[spring-tx-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
> ~[spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
> ~[spring-aop-5.0.6.RELEASE.jar:5.0.6.RELEASE]
>
> at
> org.apache.nifi.registry.service.RegistryService$$EnhancerBySpringCGLIB$$e1f05d2e.getFlowSnapshot()
> ~[nifi-registry-framework-0.2.0.jar:0.2.0]
>
> at
> org.apache.nifi.registry.web.api.FlowResource.getLatestFlowVersion(FlowResource.java:248)
> ~[classes/:na]
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[na:1.8.0_181]
>
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> Source) ~[na:1.8.0_181]
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source) ~[na:1.8.0_181]
>
> at java.lang.reflect.Method.invoke(Unknown Source)
> ~[na:1.8.0_181]
>
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:76)
> ~[jersey-server-2.26.jar:na]
>
> at
> 

Re: How to only get the newest flowfile from a queue

[scott]

Thank you for the responses Aurelien and Abdou. That reminded me that the
ListFile processor I'm using could filter with min and max age. That should
work for my use-case, as the files should only get generated once daily.

Scott

On Thu, Sep 13, 2018 at 5:43 AM Abdou B  wrote:

> Hello,
> Did you tried the standard processors getfile ?
> Minimum File Age + Maximuin File Age / Polling Interval  should get the
> job done ?
>
> Best Regards.
>
>
> Le jeu. 13 sept. 2018 à 13:50, DEHAY Aurelien 
> a écrit :
>
>> Hello.
>>
>>
>>
>> Simpliest solution in my opinion, rather than trying to do that entirely
>> in nifi, is to use an shell script and run it via ExecuteStreamCommand as
>> an input for FetchFile.
>>
>>
>>
>> -- Aurélien
>>
>>
>>
>> *From:* scott [mailto:tcots8...@gmail.com]
>> *Sent:* mercredi 12 septembre 2018 16:56
>> *To:* users@nifi.apache.org
>> *Subject:* How to only get the newest flowfile from a queue
>>
>>
>>
>> Hello community,
>>
>> I'm trying to figure out a flow that will run periodically to process the
>> latest file in a directory. If the flow doesn't run for a while, there may
>> be multiple files found. My logic does not need to process the older files
>> because the newest file always trumps the older ones, and older files can
>> be discarded. Is there a way to filter the content of a queue this way?
>>
>>
>>
>> Thanks,
>>
>> Scott
>>
>> This electronic transmission (and any attachments thereto) is intended
>> solely for the use of the addressee(s). It may contain confidential or
>> legally privileged information. If you are not the intended recipient of
>> this message, you must delete it immediately and notify the sender. Any
>> unauthorized use or disclosure of this message is strictly prohibited.
>> Faurecia does not guarantee the integrity of this transmission and shall
>> therefore never be liable if the message is altered or falsified nor for
>> any virus, interception or damage to your system.
>>
>

Re: Certificate Issue when connecting to NiFi Registry

[Mark Payne]

Hi Nikhil,

The property that you mention: "nifi.registry.security.needClientAuth" applies 
only to user logins.
This allows users to login via certificate or other methods by not requiring 
that they present a client
certificate. However, NiFi & registry require mutual authentication for all 
machine-to-machine interactions.
So in order to have NiFi talk to the registry, NiFi's cert will need to have 
client auth usage as well.

Thanks
-Mark


On Sep 13, 2018, at 5:35 AM, Nikhil Chaudhary 
mailto:nik...@acommerce.asia>> wrote:

Hey Guys,

Been stumped with a certificate issue.
A bit of info on the deployment strategy.

NiFi is running with a wildcard certificate in its keystore 
(*.domain.com) – It’s a self signed certificate.
We’ve added the Root CA in the truststore of NiFi.

We’ve used the same keystore to run NiFi registry.

So installing the Root CA on my laptop, I can access NiFi on HTTPS with no 
errors or warnings.
In theory the Root CA within the NiFi truststore should do the same when 
accessing NiFi registry, shouldn’t it?

I enabled debug logs and the error that came up was: Caused by: 
sun.security.validator.ValidatorException: Extended key usage does not permit 
use for TLS client authentication

The certificate only has serverAuth in it’s extended key usage but shouldn’t 
that be enough?
I’ve seen emails and posts online regarding NiFi clustering in which case 
clientAuth needs to be enabled but this case seems different?

ClientAuth in NiFi registry properties file is set as false.
nifi.registry.security.needClientAuth=false

Is there something I’m missing or not doing correctly?

Stack Trace:

2018-09-12 11:02:22,581 DEBUG [NiFi Registry Web Server-15] 
org.eclipse.jetty.server.HttpConnection
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529) 
~[na:1.8.0_181]
   at 
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) 
~[na:1.8.0_181]
   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) 
~[na:1.8.0_181]
   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) 
~[na:1.8.0_181]
   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.8.0_181]
   at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:621)
 ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:322)
 [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:231) 
[jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
 [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:122) 
[jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:201)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:133)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) 
[jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
   at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) 
~[na:1.8.0_181]
   at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) 
~[na:1.8.0_181]
   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) 
~[na:1.8.0_181]
   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) 
~[na:1.8.0_181]
   at 
sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1979) 

Re: How to only get the newest flowfile from a queue

[Abdou B]

Hello,
Did you tried the standard processors getfile ?
Minimum File Age + Maximuin File Age / Polling Interval  should get the job
done ?

Best Regards.


Le jeu. 13 sept. 2018 à 13:50, DEHAY Aurelien 
a écrit :

> Hello.
>
>
>
> Simpliest solution in my opinion, rather than trying to do that entirely
> in nifi, is to use an shell script and run it via ExecuteStreamCommand as
> an input for FetchFile.
>
>
>
> -- Aurélien
>
>
>
> *From:* scott [mailto:tcots8...@gmail.com]
> *Sent:* mercredi 12 septembre 2018 16:56
> *To:* users@nifi.apache.org
> *Subject:* How to only get the newest flowfile from a queue
>
>
>
> Hello community,
>
> I'm trying to figure out a flow that will run periodically to process the
> latest file in a directory. If the flow doesn't run for a while, there may
> be multiple files found. My logic does not need to process the older files
> because the newest file always trumps the older ones, and older files can
> be discarded. Is there a way to filter the content of a queue this way?
>
>
>
> Thanks,
>
> Scott
>
> This electronic transmission (and any attachments thereto) is intended
> solely for the use of the addressee(s). It may contain confidential or
> legally privileged information. If you are not the intended recipient of
> this message, you must delete it immediately and notify the sender. Any
> unauthorized use or disclosure of this message is strictly prohibited.
> Faurecia does not guarantee the integrity of this transmission and shall
> therefore never be liable if the message is altered or falsified nor for
> any virus, interception or damage to your system.
>

RE: How to only get the newest flowfile from a queue

[DEHAY Aurelien]

Hello.

Simpliest solution in my opinion, rather than trying to do that entirely in 
nifi, is to use an shell script and run it via ExecuteStreamCommand as an input 
for FetchFile.

-- Aurélien

From: scott [mailto:tcots8...@gmail.com]
Sent: mercredi 12 septembre 2018 16:56
To: users@nifi.apache.org
Subject: How to only get the newest flowfile from a queue

Hello community,
I'm trying to figure out a flow that will run periodically to process the 
latest file in a directory. If the flow doesn't run for a while, there may be 
multiple files found. My logic does not need to process the older files because 
the newest file always trumps the older ones, and older files can be discarded. 
Is there a way to filter the content of a queue this way?

Thanks,
Scott

This electronic transmission (and any attachments thereto) is intended solely 
for the use of the addressee(s). It may contain confidential or legally 
privileged information. If you are not the intended recipient of this message, 
you must delete it immediately and notify the sender. Any unauthorized use or 
disclosure of this message is strictly prohibited.  Faurecia does not guarantee 
the integrity of this transmission and shall therefore never be liable if the 
message is altered or falsified nor for any virus, interception or damage to 
your system.

Re: ExecuteSQL Avro schema: all fields are nullable

[Otto Fowler]

You should send this to the dev@ list


On September 13, 2018 at 06:41:29, christophe.mon...@post.ch (
christophe.mon...@post.ch) wrote:

Hello

Is there a reason why JdbcCommon#createSchema creates an Avro schema with
nullable types for all fields?
Why not check with java.sql.ResultSetMetaData#isNullable ?

https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.7.1/org.apache.nifi.processors.standard.ExecuteSQL/index.html

https://github.com/apache/nifi/blob/rel/nifi-1.7.1/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/util/JdbcCommon.java#L500

Regards,
Chris

ExecuteSQL Avro schema: all fields are nullable

[christophe.monnet]

Hello

Is there a reason why JdbcCommon#createSchema creates an Avro schema with 
nullable types for all fields?
Why not check with java.sql.ResultSetMetaData#isNullable ?

https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.7.1/org.apache.nifi.processors.standard.ExecuteSQL/index.html

https://github.com/apache/nifi/blob/rel/nifi-1.7.1/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/util/JdbcCommon.java#L500

Regards,
Chris

Re: Certificate Issue when connecting to NiFi Registry

[Jon Logan]

There’s an extended key usage section on the cert that is missing the
client auth usage. You can reissue the cert with client and server uses.

https://knowledge.digicert.com/solution/SO18140.html#EKU


On Thu, Sep 13, 2018 at 5:36 AM Nikhil Chaudhary 
wrote:

> Hey Guys,
>
>
>
> Been stumped with a certificate issue.
>
> A bit of info on the deployment strategy.
>
>
>
> NiFi is running with a wildcard certificate in its keystore (*.domain.com)
> – It’s a self signed certificate.
>
> We’ve added the Root CA in the truststore of NiFi.
>
>
>
> We’ve used the same keystore to run NiFi registry.
>
>
>
> So installing the Root CA on my laptop, I can access NiFi on HTTPS with no
> errors or warnings.
>
> In theory the Root CA within the NiFi truststore should do the same when
> accessing NiFi registry, shouldn’t it?
>
>
>
> I enabled debug logs and the error that came up was: *Caused by:
> sun.security.validator.ValidatorException: Extended key usage does not
> permit use for TLS client authentication*
>
>
>
> The certificate only has serverAuth in it’s extended key usage but
> shouldn’t that be enough?
>
> I’ve seen emails and posts online regarding NiFi clustering in which case
> clientAuth needs to be enabled but this case seems different?
>
>
>
> ClientAuth in NiFi registry properties file is set as false.
>
> *nifi.registry.security.needClientAuth=false*
>
>
>
> Is there something I’m missing or not doing correctly?
>
>
>
> *Stack Trace:*
>
>
>
> 2018-09-12 11:02:22,581 DEBUG [NiFi Registry Web Server-15]
> org.eclipse.jetty.server.HttpConnection
>
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>
>at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529)
> ~[na:1.8.0_181]
>
>at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
> ~[na:1.8.0_181]
>
>at
> sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
> ~[na:1.8.0_181]
>
>at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
> ~[na:1.8.0_181]
>
>at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> ~[na:1.8.0_181]
>
>at
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:621)
> ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:322)
> [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:231)
> [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
> [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
> [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258)
> [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147)
> [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
> [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
> [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:122)
> [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58)
> [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:201)
> [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:133)
> [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
> [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
> [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]
>
>at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
>
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>
>at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> ~[na:1.8.0_181]
>
>at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> ~[na:1.8.0_181]
>
>at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330)
> ~[na:1.8.0_181]
>
>at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
> ~[na:1.8.0_181]
>
>at
> sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1979)
> ~[na:1.8.0_181]
>
>at
> 

Certificate Issue when connecting to NiFi Registry

[Nikhil Chaudhary]

Hey Guys,

 

Been stumped with a certificate issue.

A bit of info on the deployment strategy.

 

NiFi is running with a wildcard certificate in its keystore (*.domain.com) – 
It’s a self signed certificate.

We’ve added the Root CA in the truststore of NiFi.

 

We’ve used the same keystore to run NiFi registry.

 

So installing the Root CA on my laptop, I can access NiFi on HTTPS with no 
errors or warnings.

In theory the Root CA within the NiFi truststore should do the same when 
accessing NiFi registry, shouldn’t it?

 

I enabled debug logs and the error that came up was: Caused by: 
sun.security.validator.ValidatorException: Extended key usage does not permit 
use for TLS client authentication

 

The certificate only has serverAuth in it’s extended key usage but shouldn’t 
that be enough?

I’ve seen emails and posts online regarding NiFi clustering in which case 
clientAuth needs to be enabled but this case seems different?

 

ClientAuth in NiFi registry properties file is set as false.

nifi.registry.security.needClientAuth=false

 

Is there something I’m missing or not doing correctly?

 

Stack Trace:

 

2018-09-12 11:02:22,581 DEBUG [NiFi Registry Web Server-15] 
org.eclipse.jetty.server.HttpConnection 

javax.net.ssl.SSLHandshakeException: General SSLEngine problem

   at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1529) 
~[na:1.8.0_181]

   at 
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) 
~[na:1.8.0_181]

   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) 
~[na:1.8.0_181]

   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) 
~[na:1.8.0_181]

   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.8.0_181]

   at 
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:621)
 ~[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:322)
 [jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:231) 
[jetty-server-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
 [jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
[jetty-io-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:122) 
[jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:201)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:133)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
 [jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]

   at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) 
[jetty-util-9.4.3.v20170317.jar:9.4.3.v20170317]

   at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]

Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem

   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) 
~[na:1.8.0_181]

   at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) 
~[na:1.8.0_181]

   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:330) 
~[na:1.8.0_181]

   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322) 
~[na:1.8.0_181]

   at 
sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1979) 
~[na:1.8.0_181]

   at 
sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:237) 
~[na:1.8.0_181]

   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) 
~[na:1.8.0_181]

   at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) ~[na:1.8.0_181]

   at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) ~[na:1.8.0_181]

   at java.security.AccessController.doPrivileged(Native Method) 
~[na:1.8.0_181]

   at