[
https://issues.apache.org/jira/browse/NIFI-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564287#comment-16564287
]
ASF GitHub Bot commented on NIFI-5473:
--------------------------------------
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.
> Add documentation for using intermediate CA with TLS toolkit
> ------------------------------------------------------------
>
> Key: NIFI-5473
> URL: https://issues.apache.org/jira/browse/NIFI-5473
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Documentation & Website, Security, Tools and Build
> Affects Versions: 1.7.1
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Major
> Labels: certificate, documentation, security, tls, tls-toolkit
>
> With some manual work, the TLS toolkit can be used with a pre-existing
> certificate and private key that has been signed by an organization's
> certificate authority (CA) to sign toolkit-generated certificates. The Admin
> Guide should be improved to cover the necessary steps.
> When the separate "Security Guide" / "Toolkit Guide" is created, this content
> should be migrated there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
