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 <eand...@pobox.com> 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/
