Support Questions

Find answers, ask questions, and share your expertise
Celebrating as our community reaches 100,000 members! Thank you!


Rising Star

Hi all,

I'm trying use listenhttp with ssl.

I've read this post :

But i don't know how use keystore from client. It is the same keystore than keystore used in ?



Super Mentor

@mayki wogno

SSL Certificates are generally issued per server. It would be extremely unusual to have multiple certificates issued for the same server or to issue certificates per piece of software. I am not saying you can't, but unnecessary.

Having said that, when you installed NiFi via Ambari, The NIfI CA that was installed likely generated the certificates needed for all your servers where NiFi is running its nodes. A quick look in the file for these jks files will reveal where to find them and the passwords for them as well (Default location on each node --> /etc/nifi/

Now here is the hitch.... When the NiFi CA generates these keystores for your NiFi nodes, the keystore and truststore on every node end up with its own unique password. This will not work for the ssl context service you need to configure to make your ListenHTTP processor operate using SSL. This is because the same identical ssl context service will be used by the listenHTTP processor on each node.

There is a little work that needs to be done on each node to get you setup here, I suggest you make a copy of the keystore.jks and truststore.jks files on every node in to some new directory. Then capture the following lines from the file on each node:<keypass><path>/keystore.jks<keystore-password><path>/truststore.jks<truststore-password>

Lets assume you create a /opt/nifi-certs/ directory n every node and placed them there.

Next you will want to use the keytool command to change the password on the copies so that uses the same password on every node, uses the same password on every node, and uses the same password on every node. While the contents of each certificate is unique to the server, the passwords used to access that key and keystore will then all be the same. This will allow you to configure your ssl-context service to use common passwords to access these server keystores on each node.

Below are the command you can use to change the keystore/trustore passwords and the key passwords within the keystore files.

For each keystore do the following:

keytool -storepasswd -new <new_storepass> -keystore keystore.jks  

(Make sure you use the same <new_storepass> on every node in your nifi cluster.

keytool -keypasswd  -alias [Alias name for private key]  -keystore [path to key store]

(If you don't know your private key <alias>, you can get it by running the following command against your keystore.jks file. You will be prompted for yoru <new_storepassword> and the original <key-password>, and then allowed to set a >new-key-password>)

keytool -v --list -keystore keystore.jks

For each Truststore do the following:

keytool -storepasswd -new <new_trustpass> -keystore truststore.jks  

(Make sure you use the same <new_trustpass> on every node in your nifi cluster.

After you have completed the above on every node you are ready to configure and start using the ssl-context service.



View solution in original post



Hi Mat,


Sorry to post my question here not getting the way out.


I have configured SSL with CA signed certs on the Server.By CA signed i mean actual CA and not NIFI CA.

I am using Nifi on a single machine without Ambari.


Now i want a client to authenticate and use nifi , how to create the client cert so that it authenticates to the CA signed cert on server.


Rising Star


I've changed my configuration Controller Service but I'm running an issue

I've checked all truststore/keystore on all the cluster, their use same passwd



Super Mentor

It does not look like you provided you key password.

Rising Star


Now that ContextServiceSSL was enabled. I need to generate keystore for my client/user ?

Super Mentor

ListenHTTP requires 2-way SSL when enabled. So the client will also need a keystore and truststore. The Truststore on both your client and server will need to contain the trusted cert entry for each others client cert. If you used the same CA for both then you should be good. If not you will need to add the CA or trusted key entry (Public key from each private key entry.) to each others Truststores.

Super Mentor

Want to add some clarity to this last comment:

ListenHTTP requires 2-way TLS when enabled if a SSLContextService has been configured with a truststore.  The truststore is used to trust the client certificate presented by the client, for the purpose of authentication, connecting to this secured ListenHTTP processor.    

If only a keystore and no truststore is configured in the SSLContext service, the ListenHTTP will not require that clients present a client certificate.

The server certificate from the keystore will be presented to the client so the client can verify that it trusts the server (NiFI listenHTTP jetty server) that it is connecting with.