With the CLI using the keystore/truststore from NiFi you shouldn't get an SSL handshake error at all, regardless of whether it was a command against NiFi or NIFi Registry.
After the SSL handshake the command could still fail based on whether the identity of the CLI has permissions to execute the command in the target system. For example, using NiFi's own identity to make a call against NiFi like "nifi pg-start ..." will probably fail with an unauthorized error unless you granted the NiFi user permission to modify components, by default the server users only have one or two permissions like /proxy and /controller. Alternatively you can also pass a proxiedEntity specifying a user that already has permission to modify components and then it should work. On Wed, Oct 24, 2018 at 10:04 AM ara m. <arama...@gmail.com> wrote: > > Thats right they are identical, and registry-dev.properties has 2 more > fields, one that is baseUrl https:// registry:port, and the other > proxiedEntity is left blank.. > > /baseUrl=https://nifi-registry.xx.local:18443 > proxiedEntity=/ > > So using those NiFi properties the CLI can only talk to the Registry, is > that right? > > Meaning these commands we expect to succeed > /> registry list-buckets -p registry-dev.properties/ > > but any command that calls to 'nifi' from the CLI, we expect to fail? > /> nifi pg-start -pgid .../ > > From inside NiFi container I am able to ping that Registry address, and the > port is indeed listening in Registry.. The url I used for Registry is the > same URL that I specified in NiFi UI for Registry and I was able to get > buckets && version flow (of my processor group). > > > > -- > Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
