Apache
/
nifi
mirror of https://github.com/apache/nifi.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

NIFI-2648 Edit formatting of TLS toolkit section of Admin guide for improved readability and consistency 

This closes #934.

Signed-off-by: Andy LoPresto <alopresto@apache.org>
This commit is contained in:
Andrew Lim 2016-08-24 16:42:59 -04:00 committed by Andy LoPresto
parent a3586e04d9
commit 7bc255b9b1
No known key found for this signature in database
GPG Key ID: 3C6EF65B2F7DEF69
1 changed files with 22 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
nifi-docs/src/main/asciidoc/administration-guide.adoc
View File

@ -172,23 +172,23 @@ accomplished by setting the `nifi.remote.input.secure` and `nifi.cluster.protoco
TLS Generation Toolkit TLS Generation Toolkit
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
In order to facilitate the secure setup of NiFi, a tls-toolkit command line utility is available 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. In order to facilitate the secure setup of NiFi, you can use the `tls-toolkit` 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.
The tls-toolkit has two primary modes of operation: The `tls-toolkit` command line tool has two primary modes of operation:
1. Standalone -- generates the certificate authority, keystores, truststores, and nifi.properties files in one command. 1. Standalone -- generates the certificate authority, keystores, truststores, and nifi.properties files in one command.
2. Client/Server mode -- uses a Certificate Authority Server that accepts Certificate Signing Requests from clients, signs them, and sends the resulting certificates back. Both client and server validate the other’s identity through a shared secret. 2. Client/Server mode -- uses a Certificate Authority Server that accepts Certificate Signing Requests from clients, signs them, and sends the resulting certificates back. Both client and server validate the other’s identity through a shared secret.
Standalone Standalone
^^^^^^^^^^ ^^^^^^^^^^
Standalone mode can be invoked by running “tls-toolkit.sh standalone -h” which will print the usage information along with descriptions of options that can be specified. Standalone mode is invoked by running `./bin/tls-toolkit.sh standalone -h` which prints the usage information along with descriptions of options that can be specified.
The most common options to specify are: The most common options to specify are:
* -n (or --hostnames) a comma-separated list of hostnames that you’d like to generate certificates for. It can be specified multiple times. Range and instance patterns are supported. (see below for details) * `-n,--hostnames` The comma-separated list of hostnames that you’d like to generate certificates for. It can be specified multiple times. Range and instance patterns are supported. See below for details.
* -C (or --clientCertDn) a DN that you'd like to generate a client certificate for. It can be specified multiple times. * `-C,--clientCertDn` The DN that you'd like to generate a client certificate for. It can be specified multiple times.
* -f (or --nifiPropertiesFile) a base nifi.properties file that the tool will update for each host * `-f,--nifiPropertiesFile` The base 'nifi.properties' file that the tool will update for each host.
* -o (or --outputDirectory) the directory to use for the resulting Certificate Authority files and NiFi configurations. A subdirectory will be made for each host. * `-o,--outputDirectory` The directory to use for the resulting Certificate Authority files and NiFi configurations. A subdirectory will be made for each host.
Hostname Patterns: Hostname Patterns:
@ -202,12 +202,12 @@ Create 4 sets of keystore, truststore, nifi.properties for localhost along with
bin/tls-toolkit.sh standalone -n 'localhost(4)' -C 'CN=username,OU=NIFI' bin/tls-toolkit.sh standalone -n 'localhost(4)' -C 'CN=username,OU=NIFI'
---- ----
Create keystore, truststore, nifi.properties for 10 nifi hostnames in each of 4 subdomains: Create keystore, truststore, nifi.properties for 10 NiFi hostnames in each of 4 subdomains:
---- ----
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain' bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain'
---- ----
Create 2 sets of keystore, truststore, nifi.properties for 10 nifi hostnames in each of 4 subdomains along with a client certificate with the given DN: Create 2 sets of keystore, truststore, nifi.properties for 10 NiFi hostnames in each of 4 subdomains along with a client certificate with the given DN:
---- ----
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain(2)' -C 'CN=username,OU=NIFI' bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain(2)' -C 'CN=username,OU=NIFI'
---- ----
@ -220,30 +220,31 @@ Client/Server mode relies on a long-running Certificate Authority (CA) to issue
===== Server ===== Server
The CA server can be invoked by running “tls-toolkit server -h” which will print the usage information. The CA server is invoked by running `./bin/tls-toolkit server -h` prints the usage information along with descriptions of options that can be specified.
The most common options to specify are: The most common options to specify are:
* -f (or --configJson) the location of the json config (written after first run) * `-f,--configJson` The location of the json config (written after first run)
* -F (or --useConfigJson) load all relevant configuration from the config json (configJson is the only other argument necessary) * `-F,--useConfigJson` Loads all relevant configuration from the config json (configJson is the only other argument necessary)
* -t (or --token) the token used to prevent man in the middle attacks (this should be a long, random value and needs to be known when invoking the client) * `-t,--token` The token used to prevent man in the middle attacks (this should be a long, random value and needs to be known when invoking the client)
* -D (or --dn) the DN for the CA * `-D,--dn` The DN for the CA
===== Client ===== Client
The client can be used to request new Certificates from the CA. The client utility will generate a keypair andCertificate Signing Request (CSR) and send the CSR to the Certificate Authority. The client can be invoked by running “tls-toolkit.sh client -h” which will print the usage information. The client can be used to request new Certificates from the CA. The client utility generates a keypair and Certificate Signing Request (CSR) and sends the CSR to the Certificate Authority. The client is invoked by running `./bin/tls-toolkit.sh client -h` which prints the usage information along with descriptions of options that can be specified.
The most common options to specify are: The most common options to specify are:
* -f (or --configJson) the json config file * `-f,--configJson` The json config file
* -c (or --certificateAuthorityHostname) the hostname of the CA * `-c,--certificateAuthorityHostname` The hostname of the CA
* -D (or --DN) the DN for the CSR (and Certificate) * `-D,--DN` The DN for the CSR (and Certificate)
* -t (or --token) the token used to prevent man in the middle attacks (this should be a long, random value and needs to be the same one used to start the CA server) * `-t,--token` The token used to prevent man in the middle attacks (this should be a long, random value and needs to be the same one used to start the CA server)
* -T (or --keyStoreType) the type of keystore to create (leave default for NiFi nodes, specify PKCS12 to create client cert) * `-T,--keyStoreType` The type of keystore to create (leave default for NiFi nodes, specify PKCS12 to create client cert)
After running the client you will have the CA’s certificate, a keystore, a truststore, and a config.json with information about them as well as their passwords. After running the client you will have the CA’s certificate, a keystore, a truststore, and a config.json with information about them as well as their passwords.
For a client certificate that can be easily imported into the browser, specify: -T PKCS12 For a client certificate that can be easily imported into the browser, specify: `-T PKCS12`
User Authentication User Authentication
------------------- -------------------