Secure NiFi cluster connected to Secure NiFi Registry: multiple nodes / multiple environments

[#1]

After following the instructions to setup a secured nifi connected to a secured nifi registry I was able to successfully create a single node setup following the instructions:
Setting Up a Secure NiFi to Integrate with a Secure NiFi Registry

However, now I need to do the same setup on a nifi cluster. 

Can anyone help to to understand how to do that?

The part that says: "Copy the keystore, nifi.properties and trustore to the conf directory of your NiFi install." On a cluster, that means I need to copy the keystore and trustore files generated initially on the registry to each node? or each node will have its own truststore.jks, keystore.jks ?

And what about if I need to setup 2 nifi cluster environments: dev and prod ? lets say 2 nodes each of them.. should copy those files to different environments as well ?

[#2]

@Pe 

Communications between a secured NiFi-Registry and a Secured NiFi cluster node or standalone NiFi instance will use a mutual TLS connection.  At a very high level...
- That means the client (NiFi node) will initiate a connection to the server (NiFi-Registry).  T
- The NiFi-Registry will responded via that handshake and present its serverAuth certificate along with a list of trusted entities (this would be the list of DNs from the trustedCertEntries found in the NiFi-Registry's truststore file). 
- The Client NiFi node will verify that it trusts the server certificate presented. This means the connecting NiFi node's truststore must contain the complete trust chain for the NiFi-registry's privateKeyEntry certificate.
- The client will then respond to that server Hello with a client hello that includes the clientAuth certificate from that NiFi nodes keystore file (Only way it will send a client certificate is if that client certificate was signed by by one of the DNs presented from the NiFi-Registry. No sense sending a client certificate back to NiFi-Registry, if NiFi-Registry is unable to trust it). 
- The NiFi-Registry will then use that DN from the NiFi client certificate to identify the connecting NiFi instance.  
- NiFi-Registry will then check that that connecting NiFi node is authorized properly.

Now many setting up additional NiFi clusters or instances, the same applies to each of those NiFi nodes when communicating to this one NiFi-Registry.
- So truststore on every NiFi node must contain the complete trust chain for the NiFi-Registry's certificate.
- The NiiFi-Registry's trustsstore file must contain the complete trust chain for the NiFi instances keystore files certificate. (Each NiFi node should have its own unique keystore file that contains only 1 PrivateKeyEntry)
- It is very common to create 1 truststore file with every needed trustedCertEntry (public certificates) and then distributed that one truststore to all instance of NiFi and NiFi-Registry.

NOTE:  The NiFi keystore files must meet following criteria.
1. Must contain ONLY 1 PrivateKeyEntry. Having more than 1 PrivateKeyEntry will not work as NiFi will not know which to use. 
2. The DN used in the PrivateKeyEntry must not contain wildcards. Since NiFi certificate is used for ClientAuth, the PrivateKeyEntry DN is what is presented to identify the node.  Many Authorizers will not support client names with wildcards, plus it is not advisable security wise.
3. The PrivateKeyEntry must have an Extended Key Usage (EKU) that supports both clientAuth and serverAuth
4. The PrivateKeyEntry must have at least 1 SAN entry that matches the hostname for the server on which the keystore is being used.

If you found this assisted with your query, please take a moment to login and click "Accept" on this solution.
Thank you,

Matt