@pnac03  1). The keystore configured in NiFi (nifi.properies and in SSL Context Service controller services) and NiFi-Registry (nifi-registry.properties) must contain only 1 PrivateKeyEntry since there is no way to control which is used when multiple exist.  The verbose output you shared for your keystore shows it containing only 1 PrivateKeyEntry. 2) TLS will negotiate the highest mutually supported version between client and server in the mTLS exchange. 3) You did not share the verbose output for the keystore used in the SSL Context Service you configured your NiFiFlowRegistry client to use.  Would also need to see the nifi-registry.properties file to inspect all the identity mapping properties set to see how the DNs might be manipulated. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@PepeVo  Without the nifi-app.log output it would be impossible for us to guess where it is failing in the startup process.   The NiFi bootstrap process simply starts the main NiFi process and monitors that child process id to make sure it still exists (NiFI has not died).   Apache NiFi should start securely out of the box without needing to make any configuration modifications to the nifi.properties file.   All you need to do is make sure Java 21 is the default java version installed on the NiFi server host first.  So my guess is issue is with some configuration you have modified from the defualt in your nifi.properties file.  Or perhaps an issue with a manual configuration you made in some other nifi configuration file within the conf directory. Thank you, Matt ... View more

@Green_  When you deploy a Dataflow (that has a parameter context assign to it) from NiFi A via NiFi-Registry to another NiFi B, the parameter context will be added to NiFi 2 if a parameter context of the same exact name does NOT already exist in NiFI 2.   If the Parameter Context with same name already exists, that local parameter context will be used.   Additionally, if the parameter context of the same name present in the original flow from NiFi has a new parameter name not present in same named pre-existing parameter context on NiFi B, that additional name/value will be added to the existing same named parameter context on NiFi B. So NiFi / NIFi-Registry was designed with the intent to handle different parameter values per NiFi deployment.   Now the first time you deploy a flow from NiFi A to NiFi B, you end up with the parameter context from NIFi A being added to NiFi B.  You'll need to update values as needed in NiFi B before starting the dataflow(s) in that Process group.  But new version after that will not be an issue (unless additional new parameter name/value pairs are added.  Those would need to be updated or you could add the new params manually in NiFi 2 before updating version. I think above solution is better since you'll have the all the parameter name/value pairs when you import the new dataflow from NiFi-Registry, you'll just need to update some values before starting the new dataflow. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@pnac03  Some clarification: The NiFi Registry Client (NifiRegistryFlowRegistryClient) will use the configured keystore and truststore in the defined SLS ContextService if configured to authenticate with the target NiFi Registry URL.  This Client Auth certificate will proxy the request on behalf of the user identity displayed in the upper right corner of the NiFi UI where this NiFi Registry client is being used.   If an SSL Context Service is not defined in the Registry client, the Registry client will use the keystore and truststore configured in the NiFi node's nifi.properties files.  Now it is common in a Nifi cluster setup that every node has its own unique keystore.  As such you would need to make sure that all the clientAuth certificates are properly authorized to proxy user requests in the target NiFi (this applies no matter which NiFi node you are logged into when making the call to NiFi-Registry since the request gets replicated by all nodes.).  That brings into question your statement below: I have verified the same even from Registry using tcpdump in my setup and I do see that the incoming CN name from nifi is CN=node-0-nifikop instead of what is referenced in the SSL Context. Can you share the verbose output for your PrivateKeyEntry?  Does it contain only 1 PrivateKey Entry or multiple?  (Must contain only one since NiFi Registry client does not provide a configuration option to specify a specific certificate by alias name. ----- Public bucket clarification: A public bucket allows any user to import a flow from that bucket to the Canvas of a NiFi.  It does not allow any user to write (start version control) of a new dataflow or commit new version of an existing version controlled dataflow to the public bucket.  Writing a new flow to a bucket will require proper write permission on the bucket regardless of whether the bucket is public or not. ------- User Identities:  The user identities coming from the ssl context services and proxied are case sensitive "User 2" and "user 2" would be treated as to different users in both NiFi and NiFi-Registry. The User identities are evaluated against any identity mappings that may be configured in the nifi-registry.properties file, so you'll want to take a look at these to make sure they are not manipulating the user identity string or clientAuth certificate DN. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@MuruganFinastra  Since you are getting a 403 response, the first thing you should do is see what user identity this 403 is being returned for.  For this you'll want to be tailing the nifi-user.log while you attempt to make this rest-api call. You will see the denied related log lines in the nifi-user.log.  That logging will provide the user identity string and which NiFi authorization policy required for which that user identity did not have the required permissions.   Using this output, we can determine the next steps required here.  Is the expected user identity being logged? What is the logged authorization policy resulting in the 403 response? Also which user authentication and authorization configuration options are you using in your setup? Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@fy-test  Apache NiFi  is only going to be able to address CVEs found in the NiFi-Registry package lib directory files included with the distribution.  Any OS/System-level CVEs would need to be addressed by the owner of the platform on which the NIFi-Registry services is being used. You can find the Apache NiFi Security Reporting here: https://nifi.apache.org/documentation/security/ You'll find CVEs already addressed in NiFi and NiFi-Registry on the above page.  You'll also see how to report any new security vulnerabilities you may discover.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Bern  Is your external Zookeeper installed on the same host as your NiFi?   If so, the load your NiFi is putting on those nodes may contribute to the performance of your ZK.  The last Apache NiFi 1.x major release version if NiFi 1.28.  I recommend upgrading to this version.  You'll potentially need to make significant changes and updated to your Apache NiFi 1.x versions dataflows before they can be used in Apache NiFi 2.x.   Apache NiFi 1.28 is also new enough that it will produce the flow.json.gz format that is also used by Apache NiFi 2.x.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Bern  The single-user-provider authentication login provider and Single-User-Authorizer are extremely basic and only intended for out-of-the-box Apache NiFi product evaluation.  Apache NiFi also generates simple self-signed certificates to support the secured connection over HTTPS.   For more robust security you should be using a different multi-user authentication provider like ldap-provider and a multi-user authorizer like the managed-authorizer.  You should also generate signed certificates.  The Self-signed certificates generated by NiFi will eventually expire. Reference: User Authentication Multi-Tenant Authorization   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more