@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

@mkobe    You comment that you have not modified your truststore.  What currently exists in the truststore.jks that you are using on all three of your nodes? keytool -v -list -keystore truststore.jks NiFi will not use the keystore for verifying certifcate trust.  It will use the configured truststore.   Also sharing the verbose output from one or more of your nodes may help get to the cottom of your issue as well. keytool -v -list -keystore keystore.jks Also make sure the following criteria against your keystore.jks: 1. Keystore.jks must contain only ONE PrivateKeyEntry. 2. PrivateKeyEntry does not use wildcards 3. PrivateKeyEntry supports clientAuth and serverAuth Extended Key Usage (EKU) 4. PrivateKeyEntry includes at least one Subject Alternative Name (SAN) entry that matches the hostname of the NiFi node on which the keystore is being used.   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

@VijaySankar    Whether a client certificate is required in the TLS connection is controlled by the server side of teh connection and not by the client. Your SSL context service must include a truststore.  The truststore is required whether the TLS secured connection is using mutual authentication or 1-way TLS authentication. The client initiates a connection to the https server.  The server responds with a TLS server hello response. Among other things, the server will include its server certificate, whether a client certificate is required (client certificate must be returned), wanted (client certificate is wanted but connection will proceed even if one is not provided), or none (no client certificate requested), and a list of server side trusted CAs.  If the server does require or want a client certificate, the client can only pass a certificate that is signed (issuer)  is one of the trusted CAs returned in the Server Hello.  If your server endpoint requires a client certificate and non is provided, the server would just close the connection since the TLS handshake failed.   The truststore used in your SSL context service on the client side must be able to trust the server certificate presented (true for mutual auth TLS or 1-way TLS).  This means the truststore you use must contain the complete trust chain for the issuer of the server certificate sent by the server.   If you want to see the server hello, you can use openssl as follows: openssl s_client -connect <server hostname>:<server port>   If you want to get the public certs for the complete trust chain from the server: openssl s_client -connect <server hostname>:<server port> -showcerts   You can copy each public cert into a cer file and import those it to your truststore used in the SSL context service if missing.   Hope this helps, Matt ... View more

@saivenkatg55    Your Out Of Memory (OOM) issue is occurring in the NiFi toolkit script and not in NiFi itself.  Ambari will execute the NiFi toolkit before the NiFi service itself is ever started.  If the NiFi toolkit fails, Ambari does not proceed any further. I can see you are running HDF 3.2.0 which exposes the heap memory settings under the NiFi configs in Ambari: Locate the above line and increase your heap settings here.  Once the toolkit script finished running which must occur before NiFi is even started, that JVM is gone.  So the memory allocation set here are short lived and will not impact available memory for your NiFi. Hope this helps, Matt   ... View more