Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2870#discussion_r201442432
--- 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.
--- End diff --
Having a SAN entry with a wildcard value is perfectly acceptable *IF* there
is another SAN with a unique value and the DN is unique. Older advice would
have just been to provide a unique DN, but with the way Google Chrome and other
tools are changing to come inline with [RFC
6125](https://tools.ietf.org/html/rfc6125#section-6.4.4), DN is no longer a
preferred definitive provider for the CN. It is supposed to be used only as a
last resort if SAN is missing. I have filed a Jira
[NIFI-5398](https://issues.apache.org/jira/browse/NIFI-5398) to improve NiFi's
handling of this situation as well.
---
