Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.7.1
Description
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.
Attachments
Issue Links
- Is contained by
-
NIFI-5458 Improve NiFi TLS and certificate management
- Resolved
-
NIFI-5476 Enable TLS Toolkit (standalone) to sign certificates with external CA certificate
- Resolved
-
NIFI-5485 Enable TLS Toolkit (client/server) to sign certificates with external CA certificate
- Resolved
- is related to
-
NIFI-5476 Enable TLS Toolkit (standalone) to sign certificates with external CA certificate
- Resolved
-
NIFI-5485 Enable TLS Toolkit (client/server) to sign certificates with external CA certificate
- Resolved
- links to
Activity
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2927
The decision to increase the Table of Contents level to 3 can be debated as well and can be split into a separate Jira/PR if necessary.
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2927
All reviews welcome, but would especially appreciate @andrewmlim @thesolson @pepov @YolandaMDavis on this if available. Thanks.
Github user andrewmlim commented on the issue:
https://github.com/apache/nifi/pull/2927
Will review and provide feedback.
Github user pvillard31 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206432068
— 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 –
Should we add a note about the addition of the root CA in the truststore? Or am I wrong when saying that all the elements of the trust chain must be added in the truststore?
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206437727
— 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 –
I beleive it depends on that the root is already added to the Java default truststore or not.
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206455131
— 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 –
At first it was a bit hard for me to understand. Maybe it could be reworded to be simpler by just saying that we can run the toolkit from the directory where the nifi-cert.pem and nifi-key.key files are located and the certs will be generated under the same directory.
Optionally the toolkit can be run from any directory by specifing the path of the nifi-cert.pem and nifi-key.key files and the target directory with a single `-o` flag.
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206439675
— 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 –
I would add that not just node but the client certificates for user authentication can be generated with this method as well.
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206455424
— 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
— End diff –
there is no flags in the example commands indicating that client certs are generated here, so it may be confusing to see this without additional info
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206582621
— 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 –
Perhaps elaborate on what the "Examples" demonstrate.
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206583792
— 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 –
Add a section title?
====== nifi-cert.pem
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206584091
— 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:
+
+```
+# The first command shows the actual content of the encoded file, and the second parses it and shows the internal values
+
+.../certs $ more nifi-cert.pem
+----BEGIN CERTIFICATE----
+MIIDZTCCAk2gAwIBAgIKAWTeM3kDAAAAADANBgkqhkiG9w0BAQsFADAxMQ0wCwYD
+VQQLDAROSUZJMSAwHgYDVQQDDBduaWZpLWNhLm5pZmkuYXBhY2hlLm9yZzAeFw0x
+ODA3MjgwMDA0MzJaFw0yMTA3MjcwMDA0MzJaMDExDTALBgNVBAsMBE5JRkkxIDAe
+BgNVBAMMF25pZmktY2EubmlmaS5hcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEF
+AAOCAQ8AMIIBCgKCAQEAqkVrrC+AkFbjnCpupSy84tTFDsRVUIWYj/k2pVwC145M
+3bpr0pRCzLuzovAjFCmT5L+isTvNjhionsqif07Ebd/M2psYE/Rih2MULsX6KgRe
+1nRUiBeKF08hlmSBMGDFPj39yDzE/V9edxV/KGjRqVgw/Qy0vwaS5uWdXnLDhzoV
+4/Mz7lGmYoMasZ1uexlH93jjBl1+EFL2Xoa06oLbEojJ9TKaWhpG8ietEedf7WM0
+zqBEz2kHo9ddFk9yxiCkT4SUKnDWkhwc/o6us1vEXoSw+tmufHY/A3gVihjWPIGz
+qyLFl9JuN7CyJepkVVqTdskBG7S85G/kBlizUj5jOwIDAQABo38wfTAOBgNVHQ8B
+Af8EBAMCAf4wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUKiWBKbMMQ1zUabD4gI7L
+VOWOcy0wHwYDVR0jBBgwFoAUKiWBKbMMQ1zUabD4gI7LVOWOcy0wHQYDVR0lBBYw
+FAYIKwYBBQUHAwIGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQAxfHFIZLOw
+mwIqnSI/ir8f/uzDMq06APHGdhdeIKV0HR74BtK95KFg42zeXxAEFeic98PC/FPV
+tKpm2WUa1slMB+oP27cRx5Znr2+pktaqnM7f2JgMeJ8bduNH3RUkr9jwgkcJRwyC
+I4fwHC9k18aizNdOf2q2UgQXxNXaLYPe17deuNVwwrflMgeFfVrwbT2uPJTMRi1D
FQyc6haF4vsOSSRzE6OyDoc/1PpyPW75OeSXeVCbc3AEAvRuTZMBQvBQUqVM51e
+MDG+K3rCeieSBPOnGNrEC/PiA/CvaMXBEog+xPAw1SgYfuCz4rlM3BdRa54z3+oO
+lc8xbzd7w8Q3
+----END CERTIFICATE----
+.../certs $ openssl x509 -in nifi-cert.pem -text -noout
+Certificate:
+ Data:
+ Version: 3 (0x2)
+ Serial Number:
+ 01:64:de:33:79:03:00:00:00:00
+ Signature Algorithm: sha256WithRSAEncryption
+ Issuer: OU=NIFI, CN=nifi-ca.nifi.apache.org
+ Validity
+ Not Before: Jul 28 00:04:32 2018 GMT
+ Not After : Jul 27 00:04:32 2021 GMT
+ Subject: OU=NIFI, CN=nifi-ca.nifi.apache.org
+ Subject Public Key Info:
+ Public Key Algorithm: rsaEncryption
+ Public-Key: (2048 bit)
+ Modulus:
+ 00:aa:45:6b:ac:2f:80:90:56:e3:9c:2a:6e:a5:2c:
+ bc:e2:d4:c5:0e:c4:55:50:85:98:8f:f9:36:a5:5c:
+ 02:d7:8e:4c:dd:ba:6b:d2:94:42:cc:bb:b3:a2:f0:
+ 23:14:29:93:e4:bf:a2:b1:3b:cd:8e:18:a8:9e:ca:
+ a2:7f:4e:c4:6d:df:cc:da:9b:18:13:f4:62:87:63:
+ 14:2e:c5:fa:2a:04:5e:d6:74:54:88:17:8a:17:4f:
+ 21:96:64:81:30:60:c5:3e:3d:fd:c8:3c:c4:fd:5f:
+ 5e:77:15:7f:28:68:d1:a9:58:30:fd:0c:b4:bf:06:
+ 92:e6:e5:9d:5e:72:c3:87:3a:15:e3:f3:33:ee:51:
+ a6:62:83:1a:b1:9d:6e:7b:19:47:f7:78:e3:06:5d:
+ 7e:10:52:f6:5e:86:b4:ea:82:db:12:88:c9:f5:32:
+ 9a:5a:1a:46:f2:27:ad:11:e7:5f:ed:63:34:ce:a0:
+ 44:cf:69:07:a3:d7:5d:16:4f:72:c6:20:a4:4f:84:
+ 94:2a:70:d6:92:1c:1c:fe:8e:ae:b3:5b:c4:5e:84:
+ b0:fa:d9:ae:7c:76:3f:03:78:15:8a:18:d6:3c:81:
+ b3:ab:22:c5:97:d2:6e:37:b0:b2:25:ea:64:55:5a:
+ 93:76:c9:01:1b:b4:bc:e4:6f:e4:06:58:b3:52:3e:
+ 63:3b
+ Exponent: 65537 (0x10001)
+ X509v3 extensions:
+ X509v3 Key Usage: critical
+ Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement, Certificate Sign, CRL Sign
+ X509v3 Basic Constraints:
+ CA:TRUE
+ X509v3 Subject Key Identifier:
+ 2A:25:81:29:B3:0C:43:5C:D4:69:B0:F8:80:8E:CB:54:E5:8E:73:2D
+ X509v3 Authority Key Identifier:
+ keyid:2A:25:81:29:B3:0C:43:5C:D4:69:B0:F8:80:8E:CB:54:E5:8E:73:2D
+
+ X509v3 Extended Key Usage:
+ TLS Web Client Authentication, TLS Web Server Authentication
+ Signature Algorithm: sha256WithRSAEncryption
+ 31:7c:71:48:64:b3:b0:9b:02:2a:9d:22:3f:8a:bf:1f:fe:ec:
+ c3:32:ad:3a:00:f1:c6:76:17:5e:20:a5:74:1d:1e:f8:06:d2:
+ bd:e4:a1:60:e3:6c:de:5f:10:04:15:e8:9c:f7:c3:c2:fc:53:
+ d5:b4:aa:66:d9:65:1a:d6:c9:4c:07:ea:0f:db:b7:11:c7:96:
+ 67:af:6f:a9:92:d6:aa:9c:ce:df:d8:98:0c:78:9f:1b:76:e3:
+ 47:dd:15:24:af:d8:f0:82:47:09:47:0c:82:23:87:f0:1c:2f:
+ 64:d7:c6:a2:cc:d7:4e:7f:6a:b6:52:04:17:c4:d5:da:2d:83:
+ de:d7:b7:5e:b8:d5:70:c2:b7:e5:32:07:85:7d:5a:f0:6d:3d:
+ ae:3c:94:cc:46:2d:43:15:0c:9c:ea:16:85:e2:fb:0e:49:24:
+ 73:13:a3:b2:0e:87:3e:ff:53:e9:c8:f5:bb:e4:e7:92:5d:e5:
+ 42:6d:cd:c0:10:0b:d1:b9:36:4c:05:0b:c1:41:4a:95:33:9d:
+ 5e:30:31:be:2b:7a:c2:7a:27:92:04:f3:a7:18:da:c4:0b:f3:
+ e2:03:f0:af:68:c5:c1:12:88:3e:c4:f0:30:d5:28:18:7e:e0:
+ b3:e2:b9:4c:dc:17:51:6b:9e:33:df:ea:0e:95:cf:31:6f:37:
+ 7b:c3:c4:37
+```
+
— End diff –
Add a section title?
====== nifi-key.key
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206591826
— Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc —
@@ -166,7 +166,7 @@ In order to facilitate the secure setup of NiFi, you can use the `tls-toolkit` c
Wildcard certificates (i.e. two nodes `node1.nifi.apache.org` and `node2.nifi.apache.org` being assigned the same certificate with a CN or SAN entry of .nifi.apache.org) are *not officially supported and not recommended. There are numerous disadvantages to using wildcard certificates, and a cluster working with wildcard certificates has occurred in previous versions out of lucky accidents, not intentional support. Wildcard SAN entries are acceptable if each cert maintains an additional unique SAN entry and CN entry.
-Potential issues with wildcard certificates:
+==== Potential issues with wildcard certificates:
— End diff –
With the TOC Level Set to 3, should change this to:
Potential Issues with Wildcard Certificates
Github user andrewmlim commented on the issue:
https://github.com/apache/nifi/pull/2927
Reviewed and added my comments. Looks good overall. +1 to changing the TOC level to 3.
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.
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206660549
— 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 –
Fair point. Will add.
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.
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206661731
— 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
— End diff –
The example directory structure is the baseline on which the prescribed commands are run. I am just showing existing output on which additional nodes can be added.
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206661946
— 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 –
Do you mean dive into what the X509 structure contains? I think that falls outside the scope of this document. If someone is concerned with that, they probably don't need this guide.
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206661989
— 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 –
Ok.
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206662040
— 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:
+
+```
+# The first command shows the actual content of the encoded file, and the second parses it and shows the internal values
+
+.../certs $ more nifi-cert.pem
+----BEGIN CERTIFICATE----
+MIIDZTCCAk2gAwIBAgIKAWTeM3kDAAAAADANBgkqhkiG9w0BAQsFADAxMQ0wCwYD
+VQQLDAROSUZJMSAwHgYDVQQDDBduaWZpLWNhLm5pZmkuYXBhY2hlLm9yZzAeFw0x
+ODA3MjgwMDA0MzJaFw0yMTA3MjcwMDA0MzJaMDExDTALBgNVBAsMBE5JRkkxIDAe
+BgNVBAMMF25pZmktY2EubmlmaS5hcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEF
+AAOCAQ8AMIIBCgKCAQEAqkVrrC+AkFbjnCpupSy84tTFDsRVUIWYj/k2pVwC145M
+3bpr0pRCzLuzovAjFCmT5L+isTvNjhionsqif07Ebd/M2psYE/Rih2MULsX6KgRe
+1nRUiBeKF08hlmSBMGDFPj39yDzE/V9edxV/KGjRqVgw/Qy0vwaS5uWdXnLDhzoV
+4/Mz7lGmYoMasZ1uexlH93jjBl1+EFL2Xoa06oLbEojJ9TKaWhpG8ietEedf7WM0
+zqBEz2kHo9ddFk9yxiCkT4SUKnDWkhwc/o6us1vEXoSw+tmufHY/A3gVihjWPIGz
+qyLFl9JuN7CyJepkVVqTdskBG7S85G/kBlizUj5jOwIDAQABo38wfTAOBgNVHQ8B
+Af8EBAMCAf4wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUKiWBKbMMQ1zUabD4gI7L
+VOWOcy0wHwYDVR0jBBgwFoAUKiWBKbMMQ1zUabD4gI7LVOWOcy0wHQYDVR0lBBYw
+FAYIKwYBBQUHAwIGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQAxfHFIZLOw
+mwIqnSI/ir8f/uzDMq06APHGdhdeIKV0HR74BtK95KFg42zeXxAEFeic98PC/FPV
+tKpm2WUa1slMB+oP27cRx5Znr2+pktaqnM7f2JgMeJ8bduNH3RUkr9jwgkcJRwyC
+I4fwHC9k18aizNdOf2q2UgQXxNXaLYPe17deuNVwwrflMgeFfVrwbT2uPJTMRi1D
FQyc6haF4vsOSSRzE6OyDoc/1PpyPW75OeSXeVCbc3AEAvRuTZMBQvBQUqVM51e
+MDG+K3rCeieSBPOnGNrEC/PiA/CvaMXBEog+xPAw1SgYfuCz4rlM3BdRa54z3+oO
+lc8xbzd7w8Q3
+----END CERTIFICATE----
+.../certs $ openssl x509 -in nifi-cert.pem -text -noout
+Certificate:
+ Data:
+ Version: 3 (0x2)
+ Serial Number:
+ 01:64:de:33:79:03:00:00:00:00
+ Signature Algorithm: sha256WithRSAEncryption
+ Issuer: OU=NIFI, CN=nifi-ca.nifi.apache.org
+ Validity
+ Not Before: Jul 28 00:04:32 2018 GMT
+ Not After : Jul 27 00:04:32 2021 GMT
+ Subject: OU=NIFI, CN=nifi-ca.nifi.apache.org
+ Subject Public Key Info:
+ Public Key Algorithm: rsaEncryption
+ Public-Key: (2048 bit)
+ Modulus:
+ 00:aa:45:6b:ac:2f:80:90:56:e3:9c:2a:6e:a5:2c:
+ bc:e2:d4:c5:0e:c4:55:50:85:98:8f:f9:36:a5:5c:
+ 02:d7:8e:4c:dd:ba:6b:d2:94:42:cc:bb:b3:a2:f0:
+ 23:14:29:93:e4:bf:a2:b1:3b:cd:8e:18:a8:9e:ca:
+ a2:7f:4e:c4:6d:df:cc:da:9b:18:13:f4:62:87:63:
+ 14:2e:c5:fa:2a:04:5e:d6:74:54:88:17:8a:17:4f:
+ 21:96:64:81:30:60:c5:3e:3d:fd:c8:3c:c4:fd:5f:
+ 5e:77:15:7f:28:68:d1:a9:58:30:fd:0c:b4:bf:06:
+ 92:e6:e5:9d:5e:72:c3:87:3a:15:e3:f3:33:ee:51:
+ a6:62:83:1a:b1:9d:6e:7b:19:47:f7:78:e3:06:5d:
+ 7e:10:52:f6:5e:86:b4:ea:82:db:12:88:c9:f5:32:
+ 9a:5a:1a:46:f2:27:ad:11:e7:5f:ed:63:34:ce:a0:
+ 44:cf:69:07:a3:d7:5d:16:4f:72:c6:20:a4:4f:84:
+ 94:2a:70:d6:92:1c:1c:fe:8e:ae:b3:5b:c4:5e:84:
+ b0:fa:d9:ae:7c:76:3f:03:78:15:8a:18:d6:3c:81:
+ b3:ab:22:c5:97:d2:6e:37:b0:b2:25:ea:64:55:5a:
+ 93:76:c9:01:1b:b4:bc:e4:6f:e4:06:58:b3:52:3e:
+ 63:3b
+ Exponent: 65537 (0x10001)
+ X509v3 extensions:
+ X509v3 Key Usage: critical
+ Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement, Certificate Sign, CRL Sign
+ X509v3 Basic Constraints:
+ CA:TRUE
+ X509v3 Subject Key Identifier:
+ 2A:25:81:29:B3:0C:43:5C:D4:69:B0:F8:80:8E:CB:54:E5:8E:73:2D
+ X509v3 Authority Key Identifier:
+ keyid:2A:25:81:29:B3:0C:43:5C:D4:69:B0:F8:80:8E:CB:54:E5:8E:73:2D
+
+ X509v3 Extended Key Usage:
+ TLS Web Client Authentication, TLS Web Server Authentication
+ Signature Algorithm: sha256WithRSAEncryption
+ 31:7c:71:48:64:b3:b0:9b:02:2a:9d:22:3f:8a:bf:1f:fe:ec:
+ c3:32:ad:3a:00:f1:c6:76:17:5e:20:a5:74:1d:1e:f8:06:d2:
+ bd:e4:a1:60:e3:6c:de:5f:10:04:15:e8:9c:f7:c3:c2:fc:53:
+ d5:b4:aa:66:d9:65:1a:d6:c9:4c:07:ea:0f:db:b7:11:c7:96:
+ 67:af:6f:a9:92:d6:aa:9c:ce:df:d8:98:0c:78:9f:1b:76:e3:
+ 47:dd:15:24:af:d8:f0:82:47:09:47:0c:82:23:87:f0:1c:2f:
+ 64:d7:c6:a2:cc:d7:4e:7f:6a:b6:52:04:17:c4:d5:da:2d:83:
+ de:d7:b7:5e:b8:d5:70:c2:b7:e5:32:07:85:7d:5a:f0:6d:3d:
+ ae:3c:94:cc:46:2d:43:15:0c:9c:ea:16:85:e2:fb:0e:49:24:
+ 73:13:a3:b2:0e:87:3e:ff:53:e9:c8:f5:bb:e4:e7:92:5d:e5:
+ 42:6d:cd:c0:10:0b:d1:b9:36:4c:05:0b:c1:41:4a:95:33:9d:
+ 5e:30:31:be:2b:7a:c2:7a:27:92:04:f3:a7:18:da:c4:0b:f3:
+ e2:03:f0:af:68:c5:c1:12:88:3e:c4:f0:30:d5:28:18:7e:e0:
+ b3:e2:b9:4c:dc:17:51:6b:9e:33:df:ea:0e:95:cf:31:6f:37:
+ 7b:c3:c4:37
+```
+
— End diff –
Ok.
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206662190
— Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc —
@@ -166,7 +166,7 @@ In order to facilitate the secure setup of NiFi, you can use the `tls-toolkit` c
Wildcard certificates (i.e. two nodes `node1.nifi.apache.org` and `node2.nifi.apache.org` being assigned the same certificate with a CN or SAN entry of .nifi.apache.org) are *not officially supported and not recommended. There are numerous disadvantages to using wildcard certificates, and a cluster working with wildcard certificates has occurred in previous versions out of lucky accidents, not intentional support. Wildcard SAN entries are acceptable if each cert maintains an additional unique SAN entry and CN entry.
-Potential issues with wildcard certificates:
+==== Potential issues with wildcard certificates:
— End diff –
I wasn't concerned with this being listed in the TOC, but good catch.
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2927
@pepov Please provide the bash history (if possible) or list the steps you took to generate those certificates which resulted in those errors. I will also try to reproduce with a TinyCert certificate. It may be that the generated cert (*intermediate CA) doesn't have the key usage for *Certificate Signing [see https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_9.0.1/admin/conf_keyusageextensionsandextendedkeyusage_r.html(Key Usage Extension and Extended Key Usage)].
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.
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2927
@pepov I was able to reproduce this. I can resolve the error you get by converting the TinyCert private key from PKCS #8 PEM format to PKCS #1 PEM format (converting from a wrapper containing the DER structure to the raw RSA key). Once this is done, there is still an error because of `Error creating generating tls configuration. (certificate does not verify with supplied key)` which is basically saying that the `nifi-cert.pem` isn't signed by itself, which is to be expected. I opened NIFI-5476(https://issues.apache.org/jira/browse/NIFI-5476) to implement this.
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r206802784
— 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 –
When I said "running the toolkit from the directory" I meant it's the working directory and not that the toolkit has to be put there. This was obvious to me, but seems it's not the cleanest wording either.
I did not try to approach this from a Docker perspective, just wanted to point out, that it was confusing for me, however I accept if you would rather stay with the original wording.
Commit 5e6c43f83ed818308bdd04d84037bdce6d13206a in nifi's branch refs/heads/master from alopresto
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=5e6c43f ]
NIFI-5473 Added section on using external signed CA for TLS Toolkit.
Increased TOC level to 3 for ASCIIDOC generated documentation.
This closes #2927.
Signed-off-by: Andrew Lim <andrewlim.apache@gmail.com>
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2927
I merged and closed this PR given @andrewmlim 's +1. I am opening a follow-on PR for NIFI-5476 which adds further documentation as well as implementing a fix for the issue identified by @pepov above in `standalone` mode. Client/server mode will be addressed in NIFI-5485.
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r207532732
— 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 –
I was thinking about how we can rollout a new CA intermediate before the old one expire.
If we add the signing external CA (referred to as the root, but I beleive it can be an intermediate as well) to the truststore we can replace the CA gradually without a complete downtime.
Is that correct @alopresto ?
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2927#discussion_r207631101
— 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 –
Yes, if the root CA signs old/current intermediate CA and new CA, and root CA is in the NiFi truststore, then certificates signed by both old intermediate CA and new CA will be trusted. You can read more about CA rollover in [IETF RFC 6489](https://tools.ietf.org/html/rfc6489).
Currently we do not and have no plans to insert the root CA certificate into the truststore. This will require new feature work if it is desired.
Commit 57baae9ae28f63877e66cbc178cdd127a82d4841 in nifi's branch refs/heads/master from alopresto
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=57baae9 ]
NIFI-5476 Added logic to check CA certificate signature against additional certificates.
Moved utility code to TlsHelper.
Added unit tests.
Added command-line parsing for additional CA certificate path.
Added documentation on using the TLS Toolkit to generate and sign certificates using an externally-signed CA.
Updated toolkit external CA documentation to be inline with additional context from NIFI-5473.
Cleaned up toolkit documentation.
Improved error message by changing to absolute path.
Added Javadoc to and removed unthrown exception declarations from TlsHelper#verifyCertificateSignature().
Cleaned up unit tests with utility method.
Fixed checkstyle error.
Support conversion of a PKCS#8 formatted private key automatically to avoid forcing the user to do that. Also add some log messages for debugging when the parser fails to parse the appropriate object
Incorporated Peter's contribution for PKCS #8 to PKCS #1 conversion.
Added documentation and refactored methods.
Refactored unit test.
Added RAT exclusion for test resource.
This closes #2935.
Co-authored-by: pepov <peterwilcsinszky@gmail.com>
Signed-off-by: Matt Gilman <mcgilman@apache.org>
GitHub user alopresto opened a pull request:
https://github.com/apache/nifi/pull/2927
NIFI-5473Added section on using external signed CA for TLS Toolkit.Increased TOC level to 3 for ASCIIDOC generated documentation.
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
in the commit message?
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/alopresto/nifi
NIFI-5473Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/2927.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2927
commit 00b74f3e706cb29c043d9d3e3627bbdd030c15b0
Author: Andy LoPresto <alopresto@...>
Date: 2018-07-31T03:47:14Z
NIFI-5473Added section on using external signed CA for TLS Toolkit.Increased TOC level to 3 for ASCIIDOC generated documentation.