@DivyaKaki    Not really sure what to tell you about the command not working for you (maybe a copy paste issue with the single quotes?).   I ran the command locally just fine. Never the less, you would not need to merge your truststore.jks files because every of your truststores already contains the same CA (localhost).   The response you are seeing in the UI indicates that your user authentication was successful; however, your authenticated user is not authorized to the requested resource (specifically /flow is needed to even see the NiFi UI canvas). You will want to be looking at the output written to the nifi-user.log when you attempt to access the NiFi UI for details about user authentication and authorization. Your users.xml and authorizations.xml files should not be empty. NiFi's file-provider from the authorizers.xml file will only generate the users.xml and authorizations.xml files if they do NOT already exist at time of NiFi startup.  Try stopping your NiFi, removing these files from all three nodes, and then starting NiFi again.  Then inspect the new files to see if they are populated. Hope this helps, Matt ... View more

@DivyaKaki  Sorry my responses were more genaralized requirements instead of the actual tls-toolkit command needed to accomplish this with the provided TLS toolkit.   When using "standalone" with NiFi TLS toolkit, all that means is that you are not using an already running  NiFi CA server. To create certificates for all three of your nodes, your tsl-toolkit.sh standalone command would look something like the following:   ./tls-toolkit.sh standalone -B <client cert password> -C 'CN=nifiadmin, OU=NIFI' -n 'node1.xyz.com,node2.xyz.com,node3.xyz.com' --nifiDnPrefix 'CN=' --nifiDnSuffix ', OU=NIFI' -o /tmp/certs/ -K <key password> -P <truststore password> -S <keystore password>   Above will create output in /tmp/certs directory (make sure directory exists before running above command).   What you end up with is the following: 1. A user certificate for nifiadmin which you can use in your browser by importing the p12 file to access your NiFi as the nifi-admin user (provided "CN=nifiadmin, OU=NIFI" was configured as your initial admin user).  2. Three folders (one for each of your nodes) containing the keystore and truststore you need to use on each of those nodes. Note: each node directory will contain a default nifi.properties file.  You should simply update your existing nifi.properties file on each node instead with the keystore and truststore required property values. You Initial Admin Identity  gets configured with the authorizers.xml file. Hope this helps, Matt ... View more

@DivyaKaki    The hostname must exist as a SAN entry in your certificate.  You may also choose to add your servers IP as a SAN entry, FQDN, internal hostname (multi-homed network), etc as SAN entries.  Each SAN entry would correspond with a unique way of addressing the server.  Localhost should not be used anywhere in a certificate (good security practice).  When you access your NiFi via a web browser you should be using one of those SAN entries in the URL. As far as the Distinguished Name (DN) goes for your certificate, NiFi does not support wildcards.  The CN within your DN can be whatever you like.  For example: CN=NiFiNode1, OU=Specialists, O=MyCompany, L=Baltimore, ST=Maryland, C=US   My cert would require following EKUs: #5: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth  I then would have SAN entries like following for example: #8: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: nifi-node-01.com DNSName: nifi-node-01 DNSName: nifi-node-internal-01   Hope this helps, Matt ... View more

@Cl0ck    There will be a HDF 3.5 release coming that is based off Apache NiFi 1.11. The next CFM release will be CFM 2.0, will be based off Apache NiFi 1.11 and will be targeted for CDP.   Thanks, Matt ... View more

@DivyaKaki    Once you configure NiFi to operate securely over https, TLS based authentication is required fro all NiFi node communications.  This requires that each node in your NiFi cluster has its own keystore.jks that meets the following criteria: 1. NiFi keystore can only contain ONE PrivateKeyEntry. 2. The keystore password must match the PriavteKeyEntry (Key password) or have no password on the key. 3. The PrivateKeyEntry can not use wildcards. 4. The PrivateKeyEntry must support both clientAuth and serverAuth ExtendedKeyUsage (EKU). 5. The PrivateKeyEntry must contain at least one Subject Alternative Name (SAN) that matches the hostname of the server on which the keystore is being used. The NiFi truststore will contain one or more TrustedCertEntries.  These are public keys used to verify trust of any presented client certificate during a TLS handshake.  You typically build one truststore which you then install on every NiFi server.  With self signed certificates, the public cert for every one of those must exist as an TrustedCertEntry in the common truststore.  Any self-signed user certificate must exist as a trustedCertEntry in the truststore as well.  If your PrivateKeyEntry was signed (issuer) by some certificate authority, then the complete certificate trust chain for that signed certificate should exist as TrustedCertEntries in your truststore.   NiFi nodes will use mutual TLS handshake when communicating with one another.  This means a NiFi nodes will be the clients at times and as servers at other times in the TLS handshake which is why the need for clientAuth and serverAuth EKUs. When it comes to user authentication in to NiFi, the default method is also TLS, thus requiring that you have a user certificate which can be trusted by the NiFi servers truststores.  NiFi can also be configured to support other methods for user authentication to include things like kerberos, LDAP, and OpenID connect. Details on how to use the NiFi TLS toolkit can be found here: https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#tls_toolkit Keep in mind that if you use this in standalone mode to create a keystore and trusttore for each node in your NiFi cluster, you will need to merge all the truststores created in to one truststore you will use on all hosts.  Plus you will need to import your user certificate public cert as well in to this truststore, so your user can authenticate. Hope this helps, Matt ... View more

@VijaySankar    What version of NiFi are your running? It is extremely likely you have encountered following bug: https://issues.apache.org/jira/browse/NIFI-6210 So if you are not running Apache NiFi 1.10 or newer, you are exposed to this bug specifically affecting the Hive 3 NiFi components.   Hope this helps, Matt ... View more