@chhaya_vishwaka  NiFi keystore requirements: 1. NiFi Keystore must contain only ONE PrivateKeyEntry 2. NiFi does not support using wildcards in certificate DNs 3. PrivateKeyEntry must support both clientAuth and serverAuth Extended Key Usage (EKU) 4. PrivateKeyEntry must contain at least one Subject Alternative Name (SAN) entry that matches the hostname on which the keystore is being used. You can obtain a verbose output of your keystore using the keytool command to verify all of the above criteria are met: keytool -v -list -keystore <your keystore file> Once above is verified, you need to make sure the truststore being used by all your NiFi nodes contains the complete certificate trust chain for your server certificates. This means if your server certificate was signed by an intermediate CA, your truststore must contain the public certificate for that intermediate CA as well as the public certificate for the signer of the intermediate CA.  Yo u may have several intermediate CAs in-line before you finally reach the rootCA (owner and issuer are the same). Once above is verified, now it should be just a matter of authenticated and authorized access to your secured NiFi.  By default when you enable TLS in NiFi, all clients/users are expected to authenticate with NiFi using a user certificate which they load in their browser.  NiFi does not have local user for purpose of authentication. NiFi can be configured to support additional forms of user authentication such as Spnego, LDAP, kerberos, OpenID connect, etc.  Refer to the admin guide and user guide for more detail.  Your browser screenshot indicates that you do not have a client/user certificates loaded in your browser which your secured NiFi can trust and since NiFi did not redirect you to login page, you do not have a login provider configured in your login-identity-providers.xml (or nifi.properties file is not configured to use it if you do). Hope this detail helps you on the path to resolving your issue, Matt ... View more

@Rohitravi    The Path Filter is applied against all subdirectories of the configured "Input Directory".  Any files found in the base "Input Directory" are still going to be listed.  If you had files in "dir4", they should not have been listed. Is dir2 empty?  If so can you change your "Input Directory" to /dir1/dir2 instead of /dir1/dir2/dir3. I cannot think of a reason why when filtering based on subdir path that you would still expect to returns from the base directory, so I filed an Apache jira ( https://issues.apache.org/jira/browse/NIFI-7104 ). Another option is to add a RouteOnAttribute processor after your listFile processor to route on only FlowFile where the absolute.path FlowFile attribute included "dir5". Then auto-terminate the unmatched relationship and route the "dir5" relationship on to the next component in your dataflow. Hope this helps, Matt If you found this solution resolves your query, please take a moment to click accept. ... View more

@DivyaKaki    Since all your certificates have been signed by the same CA, the truststore used by all nodes only needs to contain the public cert for that one CA.    Thanks, Matt ... View more

@DavidR    That is one extremely large flow.xml.gz.  I would guess that once uncompressed it falls in the ~1.5 GB size range.  My guess is that you have a large number of templates loaded in your NiFi. The Encrypt-Config toolkit serializes the flow.xml.gz in memory in order to re-encrypt the sensitive properties. The "Requested array size exceeds VM limit" is telling you that the action taken has created an array that exceeds the max JVM array size of 2^31-1 elements.  Increasing the JVM heap size will not change this max supportable array size. NiFi then ends up with no flow.xml.gz because as a result of the failed encrypt config toolkiit operation, no re-encrypted flow.xml.gz was produced as output.   So on next restart attempt of NiFi service, it starts fine and creates a blank flow.xml.gz since one did not exist. This is documented in this bug: https://issues.apache.org/jira/browse/NIFI-6999 Workaround for this issue: 1. Start your NiFi nodes from command line rather then via Ambari.  ( <path to nifi>/bin/nifi.sh start ) 2. Once NiFi cluster is back up and running, download and then delete templates stored in NiFi.   Access the global menu (upper right corner) --> Templates.  This opens a list of all stored NiFi templates.  One by one download (optional) and delete each template.  Removing stored templates does not affect anything instantiated to the canvas. These actions should greatly reduce the size of your flow.xml.gz.  Then try restarting NiFi via Ambari again. Hope this helps, Matt ... View more