Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206661495
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -281,6 +281,272 @@ After running the client you will have the CAâs
certificate, a keystore, a tru
For a client certificate that can be easily imported into the browser,
specify: `-T PKCS12`
+==== Using An Existing Intermediate Certificate Authority (CA)
+
+In some enterprise scenarios, a security/IT team may provide a signing
certificate that has already been signed by the organization's certificate
authority (CA). This *intermediate CA* can be used to sign the *node*
(sometimes referred to as *leaf*) certificates that will be installed on each
NiFi node. In order to inject the existing signing certificate into the toolkit
process, follow these steps:
+
+. Generate or obtain the signed intermediate CA keys in the following
format (see additional commands below):
+ * Public certificate in PEM format: `nifi-cert.pem`
+ * Private key in PEM format: `nifi-key.key`
+. Place the files in the *toolkit directory*. This is the directory where
the tool binary (usually called via the invoking script `tls-toolkit.sh` or
`tls-toolkit.bat`) is configured to output the signed certificates. *This is
not necessarily the directory where the binary is located or invoked*.
--- End diff --
I'll try to clean this up but I think the way it is originally is more
explicit and precise. The toolkit is unlikely to be run from the directory
containing the `nifi-cert.pem` and `nifi-key.key` files because those should be
protected and long-lived, while the toolkit may be updated multiple times over
the life of the application. In addition, if the toolkit is run from the
directory containing those files but the output directory is specified, the CA
cert and key in the output directory will be used, not the ones in the toolkit
directory.
I appreciate you're approaching this from a Kubernetes/Docker mindset,
which is necessary, but in an enterprise environment where these certs are
managed by a security team, this will not be the approach taken.
---
