@frank chen The CN for your certificate should match the FQDN of the server where you installed NiFi. Using localhost in a certificate is never a good idea from a security standpoint. Alternatively you can create a certificate that uses SAN names. These SAN names should be DNS resolvable hostnames (With a SAN entry that matches the FQDN of the server the CN does not then need to contain the FQDN. While it is possible to add a security exception in your browser for this bad server cert, you will not be able to do this should you standup a NiFi cluster where the nodes talk securely to one another. I suggest using the toolkit to generate a certificate that uses the servers FQDN as both its CN and as a Subject Alternative Name (SAN) DNS entry. That aside, where did you get your user certificate that is being used to authenticate you as a user to access NiFi? You can use the tls-tookit to create a user certificate as well which you will need to load in your browser. Alternatively, you could configure NiFi to use an external LDAP server or kerberos for user authentication. When you access a secured NiFi instance/cluster URL, the server looks for a valid user certificate it can trust in the request. If no client cert is presented to authenticate with, NiFi will check to see fi any other authentication method has been configured in NiFi. If none have been configured the connection is closed. So your issue is one of the following: 1. Your browser is not have a client (user) certificate loaded to pass to NIFi for authentication. 2. You have a user certificate but it is not trusted by your NiFi instance/cluster. The entries in the NiFi truststore.jks are used to trust the client certificates presented. The keystore typically includes a bunch Certificate authority (CA) trustedCertEntries. It may also contain the public keys of self-signed certificates as trustedCertEntries. If you found this answer addressed your question, please don't forget to mark it "accepted". Thank you, Matt ... View more

@Muhammad Umar Both ports 8078 and 8079 are likely not being forwarded by your HDP sandbox and will need to be added. https://hortonworks.com/hadoop-tutorial/sandbox-port-forwarding-guide/ Thanks, Matt ... View more

@bhumi limbu Is this error followed by a stack trace in the nifi-app.log? ... View more

@Muhammad Umar If the following command shows NiFi is still running: ./nifi.sh status and the following command shows NiFi listening on port 8079: netstat -ant|grep LISTEN Then the issue is not with NiFi. There is something external to NiFi blocking connections to port 8079 from your host where your browser is running. What OS version is running on the server/VM where NiFi is running? Thanks, Matt ... View more

@Muhammad Umar What do you see in your browser when you try to connect? What NiFi version? What browser version? When you attempt to access that URL, what do you see in the nifi-user.log? Thanks, Matt ... View more

Try using the telnet command verify you can connect to that port: telnet 172.17.0.2 8079 Thanks, Matt ... View more

@Sunil Neurgaonkar As I explained there are two levels of policies, global (controls global feature access (controller settings, provenance queries, user management, etc..) and component level access policies (controls level of user access to components added to canvas) Global policies include the following: Component level access policies include: By default components inherit the policies of the parent process group they are created in. Thanks, Matt If you found this answer helpful to your original question, please accept the answer. ... View more

@Sunil Neurgaonkar If user 1 does not have view or modify to user 2 or user 3 process groups, all user 1 will see is a ghosted boxes for those processors, remote process groups, process groups, etc. User 1 will not be able to view the configuration or FlowFiles that pass through these components either. He will not even be able to identify what kind of processor it is. The only thing they can see are the stats. This is important since all dataflows run within the same JVM. So understanding where a backlog somewhere else in the flow exists can be important. I suggest creating a label that is viewable by all users fro each process group that provides a POC for that process group in the even their is an issue. Another reason you would not want hide these components completely, is to avoid users stacking components on top of each other. Lets say user 2 can see both user 1 and user2 components, but user 1 can only see his components. User 1 now has no way of knowing where components exist making it very hard for user 2 to view the canvas since he would see all components potential layer on top of one another. Perhaps I am missing something in your use case, but I don't see the benefit or vulnerability introduced by allowoing all users to see these ghosted components. Thank you, Matt ... View more