Author: alopresto
Date: Tue Jul 17 01:56:15 2018
New Revision: 1836076
URL: http://svn.apache.org/viewvc?rev=1836076&view=rev
Log:
Added note about wildcard certificates from NIFI-5399.
Modified:
nifi/site/trunk/docs/nifi-docs/html/administration-guide.html
Modified: nifi/site/trunk/docs/nifi-docs/html/administration-guide.html
URL:
http://svn.apache.org/viewvc/nifi/site/trunk/docs/nifi-docs/html/administration-guide.html?rev=1836076&r1=1836075&r2=1836076&view=diff
==============================================================================
--- nifi/site/trunk/docs/nifi-docs/html/administration-guide.html (original)
+++ nifi/site/trunk/docs/nifi-docs/html/administration-guide.html Tue Jul 17
01:56:15 2018
@@ -935,6 +935,31 @@ accomplished by setting the <code>nifi.r
<div class="paragraph">
<p>In order to facilitate the secure setup of NiFi, you can use the
<code>tls-toolkit</code> 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.</p>
</div>
+<div class="paragraph">
+<p>Wildcard certificates (i.e. two nodes <code>node1.nifi.apache.org</code>
and <code>node2.nifi.apache.org</code> being assigned the same certificate with
a CN or SAN entry of *.nifi.apache.org) are <strong>not officially
supported</strong> and <strong>not recommended</strong>. 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. Wildcard SAN entries are acceptable
<strong>if</strong> each cert maintains an additional unique SAN entry and CN
entry.</p>
+</div>
+<div class="paragraph">
+<p>Potential issues with wildcard certificates:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>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</p>
+</li>
+<li>
+<p>Admins may need to provide a custom node identity in
<code>authorizers.xml</code> for <code>*.nifi.apache.org</code> because all
proxy actions only resolve to the cert DN (see <a
href="administration-guide.html#user_authentication">User
Authentication</a>)</p>
+</li>
+<li>
+<p>Admins have no traceability into which node performed an action because
they all resolve to the same DN</p>
+</li>
+<li>
+<p>Admins running multiple instances on the same machine using different ports
to identify them can accidentally put <code>node1</code> hostname with
<code>node2</code> port, and the address will resolve fine because itâs using
the same certificate, but the host header handler will block it because the
<code>node1</code> hostname is (correctly) not listed as an acceptable host for
<code>node2</code> instance</p>
+</li>
+<li>
+<p>If the wildcard certificate is compromised, all nodes are compromised</p>
+</li>
+</ul>
+</div>
<div class="admonitionblock note">
<table>
<tr>
@@ -7309,7 +7334,7 @@ that is specified.</p></td>
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2018-07-16 13:25:06 -07:00
+Last updated 2018-07-16 18:44:15 -07:00
</div>
</div>
</body>
