NIFi : SSL StandardSSLContextService and Keystore Truststore

[#1]

Hello,

I was setup Flow in NIFI based on KAFKA processor to consume message from KAFKA.

The communication between NIFI and KAFKA is done throught SSL. Then I need to use a StandardSSLContextService.

And I need to define the Keystore and Truststore.

As there are some flow that already use SSL in my NIFI cluster, I already have a Keystore and a Truststore.

I would like to get your opinion about the keystore and truststore strategy.

Should I use a different keystore or/and a different trustStrore from the one already defined ? Should I only backup the origine keystore/truststore and revert back to old files in case any problems appears ?

During the test should I use test keystore and test truststore, and then only integrate the certificate when everything is clean ?

And concerning the StandardSSLContextService, should i use one per keystore or truststore ? or should I create a

StandardSSLContextService per use case even if the keystore and truststore are the same ?

Best Regards
Abdou

[#2]

Hi @Abdou B.,

you need key-store only in case if you configure two way SSL from Kafka.

In regards to your trust-store you can have a common trust store across all the services you are using.

( as long as nifi - service user which runs the nifi service in Linux/Windows have read access to that trust store )

the best thing to make consistent is to have common truststore and have your keys defined with different aliases to make it more organized.

In case if you are using the two way SSL you need to configure the keystore as well, even that can be configured to use common key-store, however to keep the privates keys in secure you need to set the keypassword ( in along with the storepassword), this will ensure to use the same store across multiple teams but will not have access(use) to other team certs.

hope this will be helps !!

[#3 · Accepted solution]

@Abdou B.

The NiFi SSLContextService does not allow you to define a specific key alias to use from a keystore that contains multiple PrivateKeyEntries. So it is important that your keystore contains only a single PrivateKeyEntry that identifies the entity (user or server) that you want to use in the connection configured to use that specific keystore file.

You can create as many unique SSLContextServices as you like in NiFi. I suggest creating and naming a unique one for each different keystore you will be using. If you plan on just using the NiFi server's keystore, I would create a SSLContextService that uses the same keystore and truststore that your NiFi is using in the nifi.properties file.

Things to remember about NiFi and keystores....

1. Keystore must contain only one "PrivateKeyEntry".

2. If certificate in keystore is being used by a listening type processor (ListenTCP, ListenHTTP, etc...), it will need to support "serverAuth". If it is being used in any processor where it is connecting to an external service (consumeKafka, publishKafka, etc...) it must support "clientAuth". Your Nifi.properties keystore must support both "clientAuth" and "serverAuth"

3. In a NiFi cluster, the keystore must exist on every node in the cluster. While the certificate in each keystore can be unique, the name of the keystore file and the passwords used to access the keystore must be identical on every node.

4. A commonly used truststore file is a good practice. I makes managing you r NiFi much easier only having one truststore file to update. The Truststore can contain one to many "TrustedCertEntries". These trustedCertEntries can be the public cert for each of your identities (user or server) and/or the public cert for the various Certificate Authorities (CA) that signed those private certs (more common).

*** Keeping backup of your keystore and truststore files is always a good idea, NiFi does not write to these files and only reads them when accessed by a SSLContextService, but it is possible for a user in NiFi setup a flow that could consume these files (if local file permissions allow for it).

Thank you,

Matt

[#4]

Hello Matt,

Sorry for the delay, but I did not see your answer before.

I needed to support server and client Authentification.

I ended up using a different keystore for storing the various key I used.

Best regards

Abdou