@plapla  I see that you have configured your DistributedMapCacheClient controller service with a StandardSSLContextService.  You did not share your configuration for the needed DistributedMapCachServer.  I must assume that the server was also configured with a StandardRestrictedSSLContextService. So few things to comment on here related to DistributedMapCache: 1. You configured the client with "localhost". Does localhost exist as a SAN entry in the PrivateKeyEntry found in the Keystore used in the DistributedMapCache server's configured keystore within the StandardRestrictedSSLContextService? 2. Does the keystore PrivateKeyEntry used in the StandardSSLContext services used by the DistributedMapCacheClient service include ClientAuth as an Extended Key Usage (EKU)? 3. Using "localhost means that all nodes will be using different map caches.  The DistributedMapCacheServer starts up a separate Distributed Map Cache server on each host in the NiFi cluster. They do not communicate with one another to share cached data.  In a cluster using this specific embedded cache server it is not common to use "localhost", but rather configured the hostname of one specific host in your NiFi cluster. 4. Once you had your DistributedMapCache server setup and enabled, Did you then start your DistributedMapCacheClient service and click the validation test? 5. When you started the DistributedMapCacheServer, did any of the NiFi cluster nodes throw any exceptions in the nifi-app.log related to possible port 4557 already in use? Without the verbose output of your Keystore and truststore files (all 4 ) used by both the DistributedMapCache server and client, it would be impossible for me to tell you if they are the issue here or not.  But... I suspect you may have a MutualTLS exchange issue here. History: The DistributedMapCache (Server and Client) controller services have exists for almost as long as NiFi has existed.  They were originally implemented before NiFi offered its zero master cluster capability.  Very old versions o NiFi had a NiFi Cluster Manager (NCM) and then worker nodes that connected to that NCM.  At that time the DistributedMapCacheServer would only be installed and run on that NCM.  So DMCacheClient would always be configured to the one NCM host.  Now with Zero Master clustering there is not NCM and thus the server start a map cache server on all nodes. It is for this reason that more and newer DistributedMapCache client options are available that offer HA which is not offered through the DistributedMapCache. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@jai1gupta  Authentication is broad topic.  What have you configured so far? Is your NiFi secured over https already? With following that article where did you run into an issue? What errors or exceptions are you seeing? You should not be seeing a NiFi login window unless you have a login-identity-provider configured in your NiFi.  Probably not going to get anyone to rewrite a step-by-step process here.  You may have configuration issues unrelated to the steps for enabling the oAuth authentication method.  The more detail you can provide the better answer you will get. Aside from the Single user authentication and authorization providers, NiFi does not manage multiple local user accounts.   Authentication of multiple user is handled by some external service like oAuth provider you are trying to configure here. After Authentication comes authorization which NiFi must handle of course.  After successful authentication, NiFi has a users identity that is then used to lookup what authorizations have been granted to that user to control level of access to the NiFi UI and its features.  The File-User-Group-Provider in conjunction with the file-access-policy-provider in the authorizers.xml file are used to define and set authorization policies against a configured single user identity.  Once that user has gained access to the UI, that "admin" user will have the authorization needed to add additional user identities for the express use of assigning authorizations to them. Thanks, Matt ... View more

@AhmedParvez  Does the ConsumeMQTT or PublishMQTT processors you are using throw an exception or produce a bulletin when the connectivity is not working? If so you may be able to construct another dataflow on your NiFi canvas that can monitor for that bulletin exception and then trigger a NiFi restart or better yet, just trigger a stop and restart of the processor component which i suspect would also address your issue since all restarting NiFi is doing is restarting all components. Doing this would require adding a SiteToSiteBulletinReportingTask that would be a remote inout port that starts a new dataflow on your canvas.  You would then need to filter from all bulletins received those related to your MQTT processor. Those filtered out messages could be used to trigger a rest-api request via an InvokeHTTP processor to stop and then another to start the MQTT  processor to re-establish your connection. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@plapla  This is a completed unrelated issue to the question in this thread. To avoid confusion within the community we should keep unrelated queries in different posts. Please start a new community question for this new query.   Fee free to use @MattWho in your new question so i get notified about it. Thank you, Matt ... View more

@AhmedParvez  How is your NiFi connectivity with you IoT Hub being made? Is this a connection established through some NiFi processor or controller service component within NiFi? It is not clear to me why this connectivity issue requires a full NiFi service restart. How does restarting the service fix the connectivity? Thank you, Matt ... View more

@jai1gupta  I am not clear on your ask here and it does not seem related to the question asked and solution accepted in this thread.  Please start a new community question with details around what you are trying to accomplish/solve.  Feel free to @MattWho in that new question so that I get notified and I will try to assist you there. Thank you, Matt ... View more

@Knowledgeknow  I would think that certs created by tiny cert should be fine. Troubleshooting mutual TLS handshake this is difficult without the verbose keytool output for the NiFi keystore and truststore and the NiFi-Registry keystore and truststore. Your first screenshot with connection refused, you'll probably want to look at the nifi-registry-app.log at time you opened that UI to see what may have been logged. Can the NiFi host resolve and reach the configured Apache NiFi-Registry host?  Can this be done via the NiFi service user via command line on the NiFi host? Once you get past any potential MutualTLS issue, we would need to inspect the configurations you have in place within: NiFi: nifi.properties know what user-identity-string is currently authenticated into you secured NiFi when trying to interact with NiFi-Registry. NiFi-Registry: nifi-registry.properties authorizers.xml users.xml authorizations.xml So there is far too little information to offer up any solution or useful suggestions. Thank you, Matt ... View more

@plapla  As I mentioned in my original response, you will want tp upgrade to Apache NiFi 1.23.2+ https://nifi.apache.org/download.html I m not clear on this ask? Is there a way to update these additionally? Update what additionally? If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more