@DivyaKaki    If you are trying to harden your security, using localhost as the CN for your certificate authority is not good security practice. Your keystore PrivateKeyEntry structure is good.  You have 1 entry.  That one entry includes two certificates.  The first is for the server on which this certificate is being used.  The second is the public certificate for the CA that signed certificate 1 in this chain.  Certificate 1 has the proper EKUs and a good SAN. Please take a moment to accept the answers that helped solved your query. Matt ... View more

@Rohitravi    If you only want to list files from directory DIR5, simply provide the complete path to DIR5 in the "Input Directory" ListFile processor configuration property and set Recurse Subdirectories as false.   If above is not an option, you may want to try using the following "Path Filter": .*?/DIR5   Hope this helps, Matt ... View more

@Cl0ck    This should probably be its own question in the community... What is the purpose of building a 1 node NiFi cluster? NiFi clusters add overhead to support the zero master clustering.   - Things like zookeeper, cluster coordinators, heartbeats.... If you only ever intend to have one NiFi instance, you should just set the "is.node" to false in the nifi.properties file so your install is standalone which has no dependency on zookeeper at all. If you plan on adding additional nodes to your one node cluster, then setting up a one node cluster initially is ok. To answer your question: - 1 zookeeper node does not give you quorum.  Zookeeper should be set up using an odd number of nodes (3 or 5 nodes recommended).  Without quorum you will have issues with your NiFi cluster will cluster coordinator and primary node elections. If you found this answer addressed your questions, please accept as a solution.   Hope this helps, Matt ... View more

@DivyaKaki  It is complaining because the hostname is "ip-10-175-124-250.xxx.com" but that hostname does not exist as SAN in your certificate.   I would also be concerned that in the nifi.properties files on each of you nodes you are using localhost as your hostnames.  That will not work since that would already resolve to the server itself, so nodes would not be successful at heart beating to one another. As i mentioned much earlier, the keystore has requirements: 1. keystore can only contain ONE PrivateKeyEntry 2. PrivateKeyEntry must support clientAuth and serverAuth EKU 3. PrivateKeyEntry must contain at least one Subject Alternative Name (SAN) that matches the hostname of the server on which the certificate is being used.  In your case you have "localhost" as a SAN entry, but no SAN entry for "ip-10-175-124-250.xxx.com"   This kinda loops back around to the original command i provided that produced keystores not using localhost. On a side note, looks like after removing the users.xml, you got an expected users.xml created. Now you may be able to cheat here, but I strongly recommend against it for security reasons (but using localhost is already a bad security idea).  In the nifi.properties file, you could add each of your servers hostnames to the "nifi.web.proxy.host" property (comma separated list with no spaces). Matt ... View more

@Manus    I have never seen this.  Anytime a relationship is defined in more than one connection, the originating FlowFile will be routed to one connection and clone routed to the other(s). Perhaps you can share a some screenshots of your dataflow showing the behavior you are seeing? Screenshot of flow feeding the output port inside PG1. Screenshot of tope level interconnected Process group PG1, PG2, and PG3.   Is the input port inside PG2 connected to anything?   What version of NiFi are you using?   Thank you, Matt ... View more

@DivyaKaki    Lets take a step back for a moment here.... What is the full version of NiFi you are running currently? What is set value for following properties in your nifi.properties configuration file: nifi.security.user.authorizer=file-provider   Can you share the contents of your authorizers.xml file? Looking at what you shared earlier indicates your file-provider is commented out: <!-- <authorizer> <identifier>file-provider</identifier> <class>org.apache.nifi.authorization.FileAuthorizer</class> <property name="Authorizations File">./conf/authorizations.xml</property> <property name="Users File">./conf/users.xml</property> <property name="Initial Admin Identity">CN=NifiAdmin, OU=ApacheNIfi</property> <property name="Legacy Authorized Users File"></property> <property name="Node Identity 1">CN=localhost, OU=NIFI</property> </authorizer> Note that "<!--" indicates the start of a comment block.  The comment vlock continues until "-->" is found in the XML. The file-provider should look like this: <authorizers> <authorizer> <identifier>file-provider</identifier> <class>org.apache.nifi.authorization.FileAuthorizer</class> <property name="Authorizations File">./conf/authorizations.xml</property> <property name="Users File">./conf/users.xml</property> <property name="Initial Admin Identity">CN=NifiAdmin, OU=ApacheNIfi</property> <property name="Legacy Authorized Users File"></property> <property name="Node Identity 1">CN=localhost, OU=NIFI</property> </authorizer> </authorizers> If your provider is in fact still commented out, that will explain why your users.xml and authorizations.xml files are not being correctly built on startup.   Thank you, Matt     ... View more

@DivyaKaki    Not really sure what to tell you about the command not working for you (maybe a copy paste issue with the single quotes?).   I ran the command locally just fine. Never the less, you would not need to merge your truststore.jks files because every of your truststores already contains the same CA (localhost).   The response you are seeing in the UI indicates that your user authentication was successful; however, your authenticated user is not authorized to the requested resource (specifically /flow is needed to even see the NiFi UI canvas). You will want to be looking at the output written to the nifi-user.log when you attempt to access the NiFi UI for details about user authentication and authorization. Your users.xml and authorizations.xml files should not be empty. NiFi's file-provider from the authorizers.xml file will only generate the users.xml and authorizations.xml files if they do NOT already exist at time of NiFi startup.  Try stopping your NiFi, removing these files from all three nodes, and then starting NiFi again.  Then inspect the new files to see if they are populated. Hope this helps, Matt ... View more

@DivyaKaki  Sorry my responses were more genaralized requirements instead of the actual tls-toolkit command needed to accomplish this with the provided TLS toolkit.   When using "standalone" with NiFi TLS toolkit, all that means is that you are not using an already running  NiFi CA server. To create certificates for all three of your nodes, your tsl-toolkit.sh standalone command would look something like the following:   ./tls-toolkit.sh standalone -B <client cert password> -C 'CN=nifiadmin, OU=NIFI' -n 'node1.xyz.com,node2.xyz.com,node3.xyz.com' --nifiDnPrefix 'CN=' --nifiDnSuffix ', OU=NIFI' -o /tmp/certs/ -K <key password> -P <truststore password> -S <keystore password>   Above will create output in /tmp/certs directory (make sure directory exists before running above command).   What you end up with is the following: 1. A user certificate for nifiadmin which you can use in your browser by importing the p12 file to access your NiFi as the nifi-admin user (provided "CN=nifiadmin, OU=NIFI" was configured as your initial admin user).  2. Three folders (one for each of your nodes) containing the keystore and truststore you need to use on each of those nodes. Note: each node directory will contain a default nifi.properties file.  You should simply update your existing nifi.properties file on each node instead with the keystore and truststore required property values. You Initial Admin Identity  gets configured with the authorizers.xml file. Hope this helps, Matt ... View more

@VijaySankar    Unfortunately with the information you have shared, it is not possible for me to validate what the issue is here. I would need to output from the openssl commands i shared earlier to help. openssl s_client -connect <server hostname>:<server port> Also the verbose listing of both your keystore and truststore files would be needed:   keytool -v -list -keystore keystore.jks keytool -v -list -keystore nifi.com.jks     The target server is what decides if connection is going to use mutual auth or not.  The invokeHTTP is the client side of this connection and only provides what the server asks for in the server hello response.   It is possible also in that server hello response that the server wants a client certificate; however, the list of CAs sent in that server hello response does not contain a CA capable of trusting your clientAuth PrivateKeyEntry in your nifi.com.jks.  In that case client would not send the client certificate since server is incapable of trusting it. Matt ... View more