Hey Henk! On Tue, Jun 5, 2018 at 2:34 AM, Henk Reder <h...@yetanalytics.com> wrote:
> Hello! > > My names Henk. I'm a web developer working on getting a nifi instance setup > for some integrations. > > Long story short, I setup this nifi deployment configuration back when > 1.5.0 was the latest version. Now that its 1.6.0 everything works! > ...except one thing. > > I'm currently using tls-toolkit to setup each nodes identity in the > cluster. In order to do this, I've followed the guidelines from this post > <https://pierrevillard.com/2016/11/29/apache-nifi-1-1-0- > secured-cluster-setup/> > back > from 2016. heres a brief overview of my previously working configuration. > > *CA serverside:* > > <download tls-toolkit> > <setup a linux-user> > runuser -l <linux-user> -c '/home/nifica/bin/tls-toolkit.sh server -t > <secret-token> -D CN=<ca-hostname>,OU=NIFI&' > You are missing -c <ca-hostname> which defaults to localhost if not provided: -c,--certificateAuthorityHostname <arg> Hostname of NiFi Certificate Authority (default: localhost) Also I beleive you don't have to set -D for the default case, because it will use just what you would like to set by default: -D,--dn <arg> The dn to use for the CA certificate (default: CN=YOUR_CA_HOSTNAME,OU=NIFI) Finally: is that "&" just a copy paste error in your command, right? > > *Nifi-client side:* > > <download nifi> > <download tls-toolkit> > ./nifi-toolkit/bin/tls-toolkit.sh client -c <ca-hostname> -t > <secret-token> > --subjectAlternativeNames '<node-ip>,<node-hostname>' -D > 'CN=<node-hostname>,OU=NIFI' -T PKCS12 > > I expect the actual certs and json config to comeback after the call to the > tls-toolkit server. I can verify the request is going through but I get > these obtuse messages that tell me very little. > > > > *Nifi-client side: * > 2018/06/05 00:23:43 INFO [main] > org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient: > Requesting new certificate from <ca-hostname>:8443 > 2018/06/05 00:23:44 INFO [main] > org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPe > rformer: > Requesting certificate with dn CN=<hostname>,OU=NIFI from > <ca-hostname>:8443 > Service client error: Received response code 500 with payload > > *CA serverside: * > > 2018/06/04 22:55:50 WARN [qtp1108924067-13] > org.eclipse.jetty.server.HttpChannel: / > javax.servlet.ServletException: Server error > at > org.apache.nifi.toolkit.tls.service.server.TlsCertificateAuthorityService > Handler.handle(TlsCertificateAuthorityServiceHandler.java:99) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle( > HandlerWrapper.java:132) > at org.eclipse.jetty.server.Server.handle(Server.java:564) > at org.eclipse.jetty.server.HttpChannel.handle( > HttpChannel.java:369) > at > org.eclipse.jetty.server.HttpConnection.onFillable( > HttpConnection.java:251) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded( > AbstractConnection.java:279) > at org.eclipse.jetty.io.FillInterest.fillable( > FillInterest.java:110) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258) > at > org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147) > at org.eclipse.jetty.io.FillInterest.fillable( > FillInterest.java:110) > at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) > at > org.eclipse.jetty.util.thread.Invocable.invokePreferred( > Invocable.java:122) > at > org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke( > ExecutingExecutionStrategy.java:58) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume. > produceConsume(ExecuteProduceConsume.java:201) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run( > ExecuteProduceConsume.java:133) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( > QueuedThreadPool.java:672) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run( > QueuedThreadPool.java:590) > at java.lang.Thread.run(Thread.java:748) > 2018/06/04 22:55:50 WARN [qtp1108924067-13] > org.eclipse.jetty.server.HttpChannel: > java.lang.IllegalStateException: Error already set > at > org.eclipse.jetty.server.HttpChannelState.onError( > HttpChannelState.java:743) > at > org.eclipse.jetty.server.HttpChannel.handleException(HttpChannel.java:514) > at > org.eclipse.jetty.server.HttpChannelOverHttp.handleException( > HttpChannelOverHttp.java:463) > at org.eclipse.jetty.server.HttpChannel.handle( > HttpChannel.java:448) > at > org.eclipse.jetty.server.HttpConnection.onFillable( > HttpConnection.java:251) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded( > AbstractConnection.java:279) > at org.eclipse.jetty.io.FillInterest.fillable( > FillInterest.java:110) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:258) > at > org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:147) > at org.eclipse.jetty.io.FillInterest.fillable( > FillInterest.java:110) > at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) > at > org.eclipse.jetty.util.thread.Invocable.invokePreferred( > Invocable.java:122) > at > org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke( > ExecutingExecutionStrategy.java:58) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume. > produceConsume(ExecuteProduceConsume.java:201) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run( > ExecuteProduceConsume.java:133) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( > QueuedThreadPool.java:672) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$2.run( > QueuedThreadPool.java:590) > at java.lang.Thread.run(Thread.java:748) > > > Seeing as this code was working before, my first assumption is the problem > has something to do with some new undocumented behaviors. I fooled around > with the parameters for a bit and got very similar results, and a lot of > research and digging has left me scratching my head. I know its a 500, and > the CA server is the one throwing the exception, but I can't quite figure > out what changed and why its behaving this way. There's also no clear > indicator of what's causing the issue. I can see a callback being passed > down the stack but no message hinting at bad parameters or anything like > that. > > If it helps, this is the java version I'm running on my machine: > > > openjdk version "1.8.0_171" > OpenJDK Runtime Environment (build 1.8.0_171-b10) > OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode) > > If you have any further questions, please don't hesitate to ask. Thanks for > your time! > Henk >
