question Re: Securing a NiFi 2.0 cluster in Support Questions

Securing a NiFi 2.0 cluster

jfs912 — Mon, 21 Jul 2025 18:48:24 GMT

We want to move from NiFi 1.28.1 -> NiFi 2.4. We have done most of the prerequisites like using the json flow file not xml but are confused with the deprecation of the the ./tls-toolkit.sh. How are NiFi 2.0+ clusters secured? We are using helm charts.

Re: Securing a NiFi 2.0 cluster

MattWho — Tue, 22 Jul 2025 12:26:52 GMT

@jfs912

NiFi 2.x is secured in the same way as NiFi 1.x was secured. The Apache NIFi community made a decision to move away from providing a toolkit for generating TLS certificates since it did not make sense to have its own tool to manage certificate creation when there is nothing special the toolkit does (NIFI-12200)

. You can create your own self signed certificates (simple web search will show many resources on how to do this), you can use a certificate service to create yoru certificates and sign them for you, you can setup your own certificate authority for signing your certificates, etc. It really made no sense for Apache NiFi to maintain this code.

The important parts to remember when creating your NiFi certificates are:
Keystore for NiFi:

Must contain 1 and only 1 PrivateKey entry
PrivateKey entry DN must NOT contain wildcards. The DN is used as the client identity and use of wildcards in client identities is not a proper security practice.
PrivateKey entry must have ExtendedKeyUsage with both ClientAuth and ServerAuth. NiFi uses this certificate for both client and server authorizations
PrivateKey entry must include at least one SAN entry that matches the hostname of the NiFi server on which the certificate will be used. During a TLS exchange hostname verification is performed to make sure the hostname accessed via the URL used matches a SAN entry in the Server certificate the target server responds with. It is not uncommon for a certificate to contain more then one SAN entry.
Recommend that PrivateKey password and Keystore password are the same.

Truststore for NiFi:

The NiFi truststore contains one too many trusted cert entries. Some choose to use the Java default cacerts (truststore) file and just add the NiFi additional trusted certs entries to it. This same truststore is then used on every node in a NiFi cluster.
Must contain the complete trusts chain for the NiFi certificates. A NiFi certificate may be self signed meaning the issuer and signer are the same DistinquishedName (DN). I this case the public cert for each of yoru NiFi node's certificates needs to be added to the truststore. A NiFi certificate might be signed by an Intermediate Certificate Authority (CA). An intermediate CA would be the signer DN for the NIFi certificate. An Intermediate CA will have a different Issuer and Signer DN. The truststore must contain the public cert for this Intermediate CA. There may be multiple levels of intermediate CAs before reaching the signer that is the root CA. The root CA public certificate can be identified because it will have the same DN for issuer and signer. The truststore must contain the public certificate for the root CA. Having all the public certificates for every signer for the NiFi certificate to the Root CA makes up the complete trust chain required for trust of the signed NiFi certificate.

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

Re: Securing a NiFi 2.0 cluster

jfs912 — Tue, 11 Nov 2025 20:24:48 GMT

Matt, thanks for the response, unfortunately our deployment is a little more complicated than that. Its using a custom cetic helm chart and deployed in k8s. Considering what you said would you suggest not using the ca from cetic and just run this in a statefulset?

Re: Securing a NiFi 2.0 cluster

MattWho — Wed, 12 Nov 2025 15:11:28 GMT

@jfs912 The NiFi toolkit was removed with the NiFi 2.0 releases. See below for more details on why that decision was made.
https://lists.apache.org/thread/vn1nzobtz4fh7fs461sgg8jj9zygrk0f

I am not well versed on cetic helm charts, so not going to be able to provide specific guidance there. The bottom line is there is nothing special about toolkit generated certficates. I see no reason why you coudl not use the ca from cetic as long as the certificates meet the NiFi requirements for EKUs, SANs, Wildcards..

A NiFi or NiFi-Registry keystore:
- Must contain ONLY one PrivateKeyEntry.
- PrivateKeyEntry DN must not use wildcards.
- PrivateKeyEntry Extended Key Usage (EKU) must support ClientAuth and ServerAuth
- PrivateKeyEntry must contain one or more SAN entries. A SAN must match the hostname used by NiFi

A NiFi or NiFi-Registry Keystore. (typically same truststore is used by both):
- Must contain the complete trust chain for at clientAuth Certificate used to connect with NIFi. This includes any intermediate and root CA in the trust chain.

Thank you,
Matt