Skip to main content
DivyaKaki
DivyaKaki
Gold ⭐️
January 22, 2020
Solved

How to Generate Certs to secure 3 node nifi cluster and configs

How to Generate Certs to secure 3 node nifi cluster and configs

 

All, I am new to nifi and started to secure nifi 

can some share how to generate certs using toolkit standalone

 

Do I need to generate certs on all nodes

 

node1.xyz.com

node2.xyz.com

node3.xyz.com

 

I understand initial admin identity but what is  

Node Identity for 3 nodes i have to update in authorizers.xml file 

 

 

DivyaKaki
DivyaKakiAnswer
Gold ⭐️
February 4, 2020

Hi @MattWho one last question 

 

since i have generated certs as per hostnames with proper cn & san..

to configure truststore, do i need to merge the truststore.jks generated for both the hosts or can i use one truststore for both hosts? 

 

sh /opt/nifi-toolkit-1.9.2/bin/tls-toolkit.sh standalone -B  mypasswd -C 'CN=nifiadmin, OU=NIFI' -n 'ip-10-175-12x-xx.abc.com,ip-10-175-12x-xxx.abc.com' --nifiDnPrefix 'CN=' --nifiDnSuffix ', OU=NIFI' -o /tmp/certs_divya/ -K mypasswd -P mypasswd -S mypasswd

 

-rw-------. 1 root root 3437 Feb 3 04:46 CN=nifiadmin_OU=NIFI.p12
-rw-------. 1 root root 29 Feb 3 04:46 CN=nifiadmin_OU=NIFI.password
drwx------. 2 root root 71 Feb 3 04:46 ip-10-175-12x-xxx.abc.com
drwx------. 2 root root 71 Feb 3 04:46 ip-10-175-12x-xxx.abc.com
-rw-------. 1 root root 1200 Feb 3 04:46 nifi-cert.pem
-rw-------. 1 root root 1675 Feb 3 04:46 nifi-key.key

View in thread

22 replies

MattWho
Titanium ⭐️⭐️⭐️
MattWho
Titanium ⭐️⭐️⭐️
January 23, 2020

@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

Translate
DivyaKaki
DivyaKakiAuthor
Gold ⭐️
January 27, 2020

Thanks, @MattWho for providing details.

i am little confused here on how to merge trust store on all nodes since I'm trying on standalone  mode . can you shared details, please 

 

 

 

 

Translate
MattWho
Titanium ⭐️⭐️⭐️
MattWho
Titanium ⭐️⭐️⭐️
January 30, 2020

@DivyaKaki 

It is complaining because the hostname is "ip-10-175-124-250.xxx.com" but that hostname does not exist as SAN in your certificate.

 

I would also be concerned that in the nifi.properties files on each of you nodes you are using localhost as your hostnames.  That will not work since that would already resolve to the server itself, so nodes would not be successful at heart beating to one another.

As i mentioned much earlier, the keystore has requirements:
1. keystore can only contain ONE PrivateKeyEntry
2. PrivateKeyEntry must support clientAuth and serverAuth EKU
3. PrivateKeyEntry must contain at least one Subject Alternative Name (SAN) that matches the hostname of the server on which the certificate is being used.  In your case you have "localhost" as a SAN entry, but no SAN entry for "ip-10-175-124-250.xxx.com"

 

This kinda loops back around to the original command i provided that produced keystores not using localhost.


On a side note, looks like after removing the users.xml, you got an expected users.xml created.

Now you may be able to cheat here, but I strongly recommend against it for security reasons (but using localhost is already a bad security idea).  In the nifi.properties file, you could add each of your servers hostnames to the "nifi.web.proxy.host" property (comma separated list with no spaces).

Matt

Translate
Terms & ConditionsAccessibility statement