In order to perform any action against a secure registry or NiFi you will need to authenticate, just like if you went to one of the UI's in your browser and you provided a client cert in your browser, or logged in with LDAP/Kerberos/etc.
By specifying a truststore you are only verifying the server's identity, in this case it allows CLI to verify that NiFi Registry presented a good cert, but it is not providing any identity for the CLI to present to NiFi or NiFi Registry. You can authenticate by specifying a keystore and an optional proxied entity: https://github.com/apache/nifi/tree/master/nifi-toolkit/nifi-toolkit-cli#security-configuration The keystore could be a certificate representing a user that you made specifically for the CLI, and you would have add that use to NiFi and NiFi registry and grant that user appropriate permissions. You could also just use the keystore from NiFi since NiFi is already successfully talking to registry. On Tue, Oct 23, 2018 at 3:34 PM ara m. <[email protected]> wrote: > > Hi I've setup NiFi and NiFi registry to talk securely with 2-way SSL auth > (tls), and so have 2 separate keystores and truststores. The truststores of > each service include the cert from the other service. I am able to go to > https:// NiFI url and https:// Registry url, and see both UI's, and I am > able to create buckets, users, set proxy users in the Registry. From NiFi I > am able to version a flow, and see that flow-name appear in NiFi registry > under that bucket. So here's my question.. > > Now I am having issues using the CLI to talk from inside the container to > NiFi and the Registry. Both of my containers (I should mention I have > containerized everything), have the NiFi Toolkit installed, and both are > passing the truststore+truststore_type+truststore_pass to the NiFi / Reg, > and are getting a 1 liner exception that I am trying to debug. > > Don't have much to go on, except I know its an SSL issue. Usually a line > like this would indicate that I don't have the cert of the server that I am > trying to communicate with, but since I am inside the container of NiFi Reg, > I would think I do have the correct truststore.. so i am perplexed. > > Any directions of help? > (I have tried adding javax.net.debug to logback in NiFi nifi-user.log but > haven't seen any ssl exceptions come in, nor any java logging, so perhaps I > have a mistake there.. but this is what my next steps will be - to try to > produce more logging) > > I have tried 4 different ways to talk using the CLI (and from both > containers - NiFi and Reg). > > Calling from outside providing vars: > //opt/nifi-toolkit/nifi-toolkit-1.7.1/bin/cli.sh registry list-buckets -u > $BASE_URL -ts $TRUSTSTORE -tst $TRUSTSTORE_TYPE > / > Doing the same call but from inside the cli: > /> registry list-buckets -u $BASE_URL -ts $TRUSTSTORE -tst $TRUSTSTORE_TYPE > / > Filled out truststore (as well as keystore info) in a properties file and > calling it from outside cli and from inside: registry-dev.properties. > > /./bin/cli.sh registry list-buckets -p registry-dev.properties > / > /> registry list-buckets -p registry-dev.properties > / > I always get the same error message. > > /ERROR: Error executing command 'list-buckets' : Received fatal alert: > handshake_failure > / > Before you ask, i do use https:// and https port, and I do have the right > truststore path and password, otherwise if i provide the wrong password the > CLI complains, and also the truststore is already being used by the Registry > container to make the NiFi <-> NiFi Registry connection work. > > Thoughts? > > > > -- > Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
