Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206660100
--- 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:
--- End diff --
To clarify:
* The *intermediate CA* (let's call it `intermediateca.company.com`) is
signed by an (offline) *root CA* (`rootca.company.com`).
* The *intermediate CA* is exported to `nifi-cert.pem` (public cert) and
`nifi-key.key` private key. If the company doesn't want to do this, it can use
the *intermediate CA* to sign _another_ CA, which will be exported as
`nifi-cert.pem` and `nifi-key.key`. The only requirement here is that a
certificate which the company trusts and has the capability to sign other
certificates is exported to this format.
* The *intermediate CA* as composed of `nifi-cert.pem` and `nifi-key.key`
will be inserted into all truststores generated by the TLS toolkit. Because
this is the certificate which explicitly signed the *node* certificate, any
certificate chain validation will end here and return successfully.
* The *root CA* does not need to be present in any generated truststore.
* The Java default truststore (`$JAVA_HOME/jre/lib/security/cacerts`) does
not enter into this process at all.
---
