Re: NiFi toolkit (tls-toolkit.sh server mode) and internally facing Web interface issue + nifi-cli to automate flows
I am currently working on these issues and will share the PR when it is in a stable and acceptable state. Because of the way the toolkit is currently structured, 5460 needs 5462 to happen first. This is why the feature parity doesn’t exist; I added the feature to standalone mode but client/server mode needs additional changes to make it work. Andy LoPresto alopre...@apache.org alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Feb 13, 2019, at 7:55 AM, Erik Anderson wrote: > >> Andy LoPresto >> alopre...@apache.org >> alopresto.apa...@gmail.com > > Thanks for the reply. I tried the steps you lined but but the only feasible > option is as lined out below, feature parity with the standalone mode. > >> The quick answer is that there is currently a feature availability >> difference between the standalone mode and the client/server mode of >> the TLS Toolkit. The behavior you are requesting is currently in the >> standalone mode but not in the client/server mode. This is due to a >> difference in their implementation logic, which is being addressed as >> part of a larger refactoring under NIFI-5462 [1], which is a component >> of the TLS Toolkit epic NIFI-5458 [2]. > > Is this in progress? I am happy to pick this up and do it per guidance. Its > an important feature. > >> Example keytool output for keystore with external CA public certificate >> in chain: > >> Owner: CN=intermediate_signed.nifi.apache.org, OU=NIFI >> Issuer: CN=Intermediate CA > >> Owner: CN=Intermediate CA >> Issuer: CN=Root CA > > In my experience, getting a Sub-CA in an enterprise organization is a > challenge and it exposes other risks. Its easier for me to code up a solution > for everyone. :) > >> The NiFi TLS Toolkit was designed to facilitate the deployment and >> configuration of TLS behavior _in an environment lacking an enterprise >> security team_. > > I wish an enterprise was that simple. Many times people need to take > ownership themselves. Thats why offer to code up feature parity. > >> I am sorry the PKIX error message is unclear. The error is a >> Java-native exception and we can make an effort to capture it and >> provide a more user-friendly message in the future. However, searching >> "PKIX path building failed nifi” [7] does return a number of helpful >> articles and Q/A posts with instructions to resolve the issue. > > I usually catch the error, add a little more content to the error message, > and re-throw it. It does give the bes of both worlds. > >> I encourage you to share further thoughts on concrete steps to improve >> this process that do not open users up to unseen security risks, and to >> follow the Jiras discussed above for further developments in improving >> the behavior and ease-of-use of the TLS Toolkit. > > I agree. If there is no one working on > - https://issues.apache.org/jira/browse/NIFI-5460 > > I will happily help and coordinate with whomever is working on > - https://issues.apache.org/jira/browse/NIFI-5462 > > Erik Anderson > Bloomberg > https://www.linkedin.com/in/erikanderson/
Re: NiFi toolkit (tls-toolkit.sh server mode) and internally facing Web interface issue + nifi-cli to automate flows
> Andy LoPresto > alopre...@apache.org > alopresto.apa...@gmail.com Thanks for the reply. I tried the steps you lined but but the only feasible option is as lined out below, feature parity with the standalone mode. > The quick answer is that there is currently a feature availability > difference between the standalone mode and the client/server mode of > the TLS Toolkit. The behavior you are requesting is currently in the > standalone mode but not in the client/server mode. This is due to a > difference in their implementation logic, which is being addressed as > part of a larger refactoring under NIFI-5462 [1], which is a component > of the TLS Toolkit epic NIFI-5458 [2]. Is this in progress? I am happy to pick this up and do it per guidance. Its an important feature. > Example keytool output for keystore with external CA public certificate > in chain: > Owner: CN=intermediate_signed.nifi.apache.org, OU=NIFI > Issuer: CN=Intermediate CA > Owner: CN=Intermediate CA > Issuer: CN=Root CA In my experience, getting a Sub-CA in an enterprise organization is a challenge and it exposes other risks. Its easier for me to code up a solution for everyone. :) > The NiFi TLS Toolkit was designed to facilitate the deployment and > configuration of TLS behavior _in an environment lacking an enterprise > security team_. I wish an enterprise was that simple. Many times people need to take ownership themselves. Thats why offer to code up feature parity. > I am sorry the PKIX error message is unclear. The error is a > Java-native exception and we can make an effort to capture it and > provide a more user-friendly message in the future. However, searching > "PKIX path building failed nifi” [7] does return a number of helpful > articles and Q/A posts with instructions to resolve the issue. I usually catch the error, add a little more content to the error message, and re-throw it. It does give the bes of both worlds. > I encourage you to share further thoughts on concrete steps to improve > this process that do not open users up to unseen security risks, and to > follow the Jiras discussed above for further developments in improving > the behavior and ease-of-use of the TLS Toolkit. I agree. If there is no one working on - https://issues.apache.org/jira/browse/NIFI-5460 I will happily help and coordinate with whomever is working on - https://issues.apache.org/jira/browse/NIFI-5462 Erik Anderson Bloomberg https://www.linkedin.com/in/erikanderson/
Re: NiFi toolkit (tls-toolkit.sh server mode) and internally facing Web interface issue + nifi-cli to automate flows
Hi Erik, Thanks for reaching out for assistance on this topic. I’ll try to answer your questions in order. > Short Version: > When running the NiFi toolkit ../bin/tls-toolkit.sh server, how do I get the > server to include an additional public certificate of authority in the > returned truststore.jks file (../bin/tls-toolkit.sh client calls) The quick answer is that there is currently a feature availability difference between the standalone mode and the client/server mode of the TLS Toolkit. The behavior you are requesting is currently in the standalone mode but not in the client/server mode. This is due to a difference in their implementation logic, which is being addressed as part of a larger refactoring under NIFI-5462 [1], which is a component of the TLS Toolkit epic NIFI-5458 [2]. If you need that functionality out of the box right now, using the standalone mode with the --additionalCACertificate flag [3] will allow you to provide further CA certificates into the signing process. However, there is a current workaround for the client/server mode which may be acceptable to you. Rather than manually signing each issued node certificate with your enterprise CA, you can sign the NiFi CA certificate with the enterprise CA (following the same CSR steps you already do), and then subsequent signing operations using the toolkit should propagate this information via the certificate chain. There are explicit instructions for performing these actions in the Admin Guide under "Using An Existing Intermediate Certificate Authority (CA)” [4] and "Signing with Externally-signed CA Certificates” [5]. I’ve also included example output below showing a keystore containing a private key entry with 2 certificates demonstrating the Root CA signing an Intermediate CA, which signed the node certificate. Your further questions are regarding the configuration of shared trust with the NiFi Registry instance. I’ll offer some quick background in response to your last statements and then try to address each component directly. The NiFi TLS Toolkit was designed to facilitate the deployment and configuration of TLS behavior _in an environment lacking an enterprise security team_. By design, the toolkit assumes a completely isolated environment where an individual admin was deploying NiFi as a proof of concept, development system. The toolkit is _not_ designed to replace an enterprise security team, and in environments where this expertise and these services are available, that process should be followed. I am sorry if the documentation feels lacking to you. These are very complicated processes, and it’s written to be targeted to an “advanced beginner” — someone who understands the general concepts but isn’t familiar with every openssl setting, and benefits from some level of abstraction. With that in mind, we still tried to make the steps clear for the common use cases we expect users to encounter. If you have suggestions for improving the documentation (specific steps that were unclear, etc.) we welcome those. In response to the specific issue you are encountering, I am surprised this is occurring. The toolkit is designed to issue certificates properly signed with the CA, so any “node” should be trusted automatically. I understand this seems pedantic, but definitions and terminology are critical in security, so I want to clarify that your command to issue a certificate for NiFi Registry is not issuing a _client_ certificate. It is issuing a server certificate which will be used in a server role when the Registry is hosting a web service (API/UI) and external entities connect to it (Registry Client in NiFi, a user via browser, the NiFi CLI toolkit, etc.). The command you’re using to issue a cert for the CLI is doing the same thing. The instructions on configuring security for the CLI [6] assume you are using an actual _client_ certificate, for example one issued for a human user which has been loaded into the browser to allow authenticated access. The differences in issuing a _client_ certificate include the command-line flags for the toolkit (-C), the key usages and roles assigned, the output format (JKS vs PKCS12), etc. I am sorry the PKIX error message is unclear. The error is a Java-native exception and we can make an effort to capture it and provide a more user-friendly message in the future. However, searching "PKIX path building failed nifi” [7] does return a number of helpful articles and Q/A posts with instructions to resolve the issue. Your statement about needing to run a meddler-in-the-middle is confusing to me. It appears that the issued truststore does not contain the specific CA entry you need in order to form a complete certificate chain and authenticate the service. A MitM won’t resolve this, and the commands you included don’t run a MitM; rather you make a TLS connection to the server using openssl s_client and retrieve the server’s public
Re: NiFi toolkit (tls-toolkit.sh server mode) and internally facing Web interface issue + nifi-cli to automate flows
I created a JIRA here. https://issues.apache.org/jira/browse/NIFI-6012 To track this request to add additional certificates to the truststore.jks Erik Anderson Bloomberg
NiFi toolkit (tls-toolkit.sh server mode) and internally facing Web interface issue + nifi-cli to automate flows
I am not sure if this is a NiFi dev or NiFi user question. Seems more dev based Short Version: When running the NiFi toolkit ../bin/tls-toolkit.sh server, how do I get the server to include an additional public certificate of authority in the returned truststore.jks file (../bin/tls-toolkit.sh client calls) Long version: When running tls-toolkit.sh as the CA for NiFi instances ../bin/tls-toolkit.sh server -D "CN=nifi-ca.blah.blah.bloomberg.com, OU=NIFI" -t mysupersecrettoken-p 8443 -d 1826 And I call the CA to request a /bb/nifi-toolkit/nifi-toolkit-1.7.1/bin/tls-toolkit.sh client -c nifi-ca.blah.com -t mysupersecrettoken-p 8443 -D "CN=nifi-myproject.blah.blah.bloomberg.com, OU=NIFI, O=Bloomberg L.P., L=New York, ST=New York, C=US" The toolkit gives me a keystore.jks I need to get this certificate signed by an external entity so I dont have issues with the browsers. Basically I do keytool -certreq -alias nifi-key -file csr.txt -keystore keystore.jks I the the certificate signing request, csr.txt, I feed it to the public certificate of authority, I get a signed certificate back. I convert the format of the certificate like so openssl x509 -outform der -in new_cert.pem -out new_cert.crt Now I import the certificate back into my keystore. keytool -import -alias nifi-key -file new_cert.crt -keystore keystore.jks Now I have solved the certificate warning errors in the browser when I connect to the NiFi UI. Now I want to use the NiFi cli to to automate data flows between the registry and the NiFi instances so I generate a client cert 2) ../bin/tls-toolkit.sh client -c nifi-ca.blah.blah.bloomberg.com -t mysupersecrettoken-p 8443 -D "CN=nifi-cli, OU=NIFI" -T PKCS12 I setup nifi.prop, I also add "CN=nifi-cli, OU=NIFI" as a user to the NiFi UI Now I call the NiFi instane as so ../bin/cli.sh nifi pg-list -verbose -p /bb/nifi-toolkit/nifi-toolkit-1.7.1/nifi.prop And I get this error org.apache.nifi.toolkit.cli.api.CommandException: Error executing command 'pg-list' : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target *** BTW, this error message and it gives you little to go on. Really sucks. Its not covered in any mailing list, topics, howto, nothing. This is a massive issue at an enterprise company. Regardless I figure this out. *** To fix this problem, anytime I call the ../bin/tls-toolkit.sh client I need to install my own man-in-the-middle and extract the root certificate like so openssl s_client -connect nifi-myproject.blah.blah.bloomberg.com:443 -showcerts Extract the root CA certificate post modify the truststore.jks file to include the root CA certificate that signed the .csr cat > /bb/nifi-toolkit/nifi-toolkit-1.7.1/certs/digicert.crt <
