Potential issues with wildcard certificates
In many places throughout the codebase, cluster communications use certificate identities many times to identify a node, and if the certificate simply presents a wildcard DN, that doesn't resolve to a specific node
Admins may need to provide a custom node identity in authorizers.xml for
*.nifi.apache.orgbecause all proxy actions only resolve to the cert DN
Admins have no traceability into which node performed an action because they all resolve to the same DN
Admins running multiple instances on the same machine using different ports to identify them can accidentally put
node2port, and the address will resolve fine because it's using the same certificate, but the host header handler will block it because the
node1hostname is (correctly) not listed as an acceptable host for
If the wildcard certificate is compromised, all nodes are compromised
JKS keystores and truststores are recommended for NiFi. This tool allows the specification of other keystore types on the command line but will ignore a type of PKCS12 for use as the truststore because that format has some compatibility issues between BouncyCastle and Oracle implementations.
tls-toolkit command line tool has two primary modes of operation:
Standalone - generates the certificate authority, keystores, truststores, and nifi.properties files in one command.
Client/Server mode - uses a Certificate Authority Server that accepts Certificate Signing Requests from clients, signs them, and sends the resulting certificates back. Both client and server validate the other's identity through a shared secret.