[ https://issues.apache.org/jira/browse/NIFI-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539043#comment-16539043 ]
ASF GitHub Bot commented on NIFI-5399: -------------------------------------- Github user alopresto commented on a diff in the pull request: https://github.com/apache/nifi/pull/2870#discussion_r201441269 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -164,6 +164,16 @@ accomplished by setting the `nifi.remote.input.secure` and `nifi.cluster.protoco In order to facilitate the secure setup of NiFi, you can use the `tls-toolkit` command line utility to automatically generate the required keystores, truststore, and relevant configuration files. This is especially useful for securing multiple NiFi nodes, which can be a tedious and error-prone process. +Wildcard certificates (i.e. two nodes `node1.nifi.apache.org` and `node2.nifi.apache.org` being assigned the same certificate with a CN or SAN entry of +*.nifi.apache.org+) are *not officially supported* and *not recommended*. There are numerous disadvantages to using wildcard certificates, and a cluster working with wildcard certificates has occurred in previous versions out of lucky accidents, not intentional support. + +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.org` because all proxy actions only resolve to the cert DN (see <<user_authentication>>) +* Admins have no traceability into which node performed an action because they all resolve to the same DN +* Admins running running multiple instances on the same machine using different ports to identify them can accidentally put `node1` hostname with `node2` port, it will resolve fine because it’s using the same certificate, but the host header handler will block it because the `node1` hostname is (correctly) not listed as an acceptable host for `node2` instance --- End diff -- Ack. > Improve documentation to indicate that wildcard certificates are not > recommended for cluster communications > ----------------------------------------------------------------------------------------------------------- > > Key: NIFI-5399 > URL: https://issues.apache.org/jira/browse/NIFI-5399 > Project: Apache NiFi > Issue Type: Improvement > Components: Documentation & Website > Affects Versions: 1.7.0 > Reporter: Andy LoPresto > Assignee: Andy LoPresto > Priority: Major > Labels: certificate, cluster, documentation, security, tls > > Based on the research from NIFI-5370 and potential changes in NIFI-5398, the > Admin Guide should be improved to explain why wildcard certificates without a > unique SAN are not recommended for secure cluster configurations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)