[
https://issues.apache.org/jira/browse/NIFI-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564445#comment-16564445
]
ASF GitHub Bot commented on NIFI-5473:
--------------------------------------
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206707072
--- 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*.
+ * For example, given the following scenario, the toolkit command can be
run from its location as long as the output directory `-o` is `../hardcoded/`,
and the existing `nifi-cert.pem` and `nifi-key.key` will be used.
+ ** e.g. `$ ./toolkit/bin/tls-toolkit.sh standalone -o ./hardcoded/ -n
'node4.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` will
result in a new directory at `./hardcoded/node4.nifi.apache.org` with a
keystore and truststore containing a certificate signed by
`./hardcoded/nifi-key.key`
+ * If the `-o` argument is not provided, the default working directory
(`.`) must contain `nifi-cert.pem` and `nifi-key.key`
+ ** e.g. `$ cd ./hardcoded/ && ../toolkit/bin/tls-toolkit.sh standalone
-n 'node5.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O`
+
+```
+🔓 0s @ 18:07:58 $ tree -L 2
+.
+├── hardcoded
+│  ├── CN=myusername.hardcoded_OU=NiFi.p12
+│  ├── CN=myusername.hardcoded_OU=NiFi.password
+│  ├── nifi-cert.pem
+│  ├── nifi-key.key
+│  ├── node1.nifi.apache.org
+│  ├── node2.nifi.apache.org
+│  └── node3.nifi.apache.org
+└── toolkit
+   ├── LICENSE
+   ├── NOTICE
+   ├── README
+   ├── bin
+   ├── conf
+   ├── docs
+   └── lib
+```
+
+===== Additional Commands
+
+The `nifi-cert.pem` and `nifi-key.key` files should be ASCII-armored
(Base64-encoded ASCII) files containing the CA public certificate and private
key respectively. Examples:
--- End diff --
No, I just meant elaborate so "Examples" is a quick sentence summarizing
what they show. Not critical.
> 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)
