@Pr1    While I am not an IMAP expert, the exception you are seeing here: PKIX path building failed. unable to find valid certification path This is a TLS handshake exception telling you that the complete certificate trust chain does not exist in the keystore.  On the NiFi side the complete trust chain would found in the NiFi truststore.jks.  Note: If NiFi is not secured you may need to add the trust chain certs to the NiFI java's default cacerts keystore. You can use openssl to get the complete trust chain for the IMAP server you are trying to consume from: openssl s_client -connect <IMAP server>:<IMAP port> -showcerts In the server hello response returned from the IMAP server using above command, you will see multiple certificates.  First certificate is the imap server's public certificate (you do not need this one).  You will need all the public certificates that follow that server certificate.  These will be your Signing CAs (there may be one or more in order of signing until you reach the rootCA). The rootCa is last and you will notice the owner and issuer DN is the same. Each certificate begins with: -----BEGIN CERTIFICATE----- and ends with: -----END CERTIFICATE-----   So you want to copy each certificate including the above lines to separate files: Eaxamples: intermediate.pem, intermediate2.pem, rootCA.pem  You can then use keytool to import these CAs in to your NiFi truststore. keytool -importcert -alias <alias usually based off CN name for certiifcate> -file <certificate.pem> -keystore <truststore.jks or java cacerts> -trustcacerts Note: each certificate imported must use a unique alias.   I recommend importing your certificates in the same order as they were listed in openssl response (importing the rootCA last). Restart your NiFi so it loads the modified keystore. Hope this helps resolve your trust chain issue, Matt ... View more

@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