I spent a bit of time working on a draft of the needed openssl commands to generate equivalent keystores / truststores. Was not able to finish this draft before I got side tracked.
https://github.com/greyp9/nifi-tidbits/blob/main/cluster/tls-toolkit-via-openssl/cluster-certs.md If you're still offering, I would be interested to see the equivalent keytool commands, to compare and contrast. Maybe both could be documented... If we can reduce or eliminate the needed maintenance efforts associated with TLS Toolkit, this seems worth some one-time effort. On Sun, Sep 17, 2023 at 1:46 AM Matthew Hawkins <hawko2...@gmail.com> wrote: > NiFi in certain configurations requires a specific set of x509_v3 > extensions, e.g. when using InvokeHTTP. This is automatically added when > using TLS Toolkit but all other options relies upon the CA either accepting > and passing through extensions in the request, or specifically adding them > in. > > You cannot use a stock standard web cert signing authority as they usually > ignore passed extensions and just sign a server-only cert, which will > result in a dysfunctional NiFi. ADCS doesn't have a valid default template > for NiFi and many installations of that don't deviate from default > templates. > > If you don't use certain processors it's certainly easy to just sign a > server cert and not know anything is amiss. This shouldn't be the default. > It's 15 sequential Java keytool commands to build a proper CA chain and > sign a NiFi cert. If TLS Toolkit is being pulled, a script to invoke > keytool should be included at the same time. > > I'm happy to provide a basic solution to this if asked. > > I like keytool as it is available on all platforms and uses the right > formats NiFi requires for keystore and truststore. The open source Keytool > Explorer is also a nice way to build and manage the stores, not strictly > necessary but nice to have. > > > > > On Thu, 14 Sept 2023, 05:58 Kevin Doran, <kdo...@apache.org> wrote: > > > I agree that tis toolkit can probably be removed in 2.0, and I would add > > that tinycert.org provides another option for teams that need to setup > > dev/test environments with trusted certificates. > > > > Thanks, > > Kevin > > > > On Sep 13, 2023 at 11:46:19, David Handermann < > exceptionfact...@apache.org > > > > > wrote: > > > > > Hi Isha, > > > > > > Thanks for the helpful reply. I agree that the TLS Toolkit is most > > > convenient for development and lab deployments, and that's where we > > > should be able to provide some documentation for alternatives. The > > > existing Secure Cluster Walkthrough is a helpful reference for TLS > > > Toolkit usage, so if we updated that to provide similar guidance using > > > other tools, that would be useful. > > > > > > Getting everything right with TLS can be challenging, but when it > > > comes to project maintenance, it seems better to focus on core > > > capabilities and not maintain the TLS Toolkit if the primary use case > > > is for non-production deployments. > > > > > > The encrypt-config command is a different question, but a very good > > > question. It includes functionality that is very specific to NiFi, and > > > it is also in need of refactoring. The threat model for containerized > > > deployments may be somewhat different than running directly on > > > physical hardware. With the need to support various approaches, > > > however, some type of configuration encryption remains a relevant > > > concern. > > > > > > Regards, > > > David Handermann > > > > > > On Wed, Sep 13, 2023 at 10:19 AM Isha Lamboo > > > <isha.lam...@virtualsciences.nl> wrote: > > > > > > > > > Hi David, > > > > > > > > > My primary use for the TLS toolkit is for lab deployments, mostly > during > > > in-house trainings. I will miss the convenience of having a full set of > > > keystores and truststores ready to go with a single command, but then > > > again, a few commands in a script should replicate this well enough, > > > without the need for maintaining the toolkit. > > > > > > > > > I see no obstacles to adopting NiFi 2.0 if the TLS toolkit is phased > out, > > > from the perspective of the deployments I manage. > > > > > > > > > On a side note: How relevant is the encrypt config part of the toolkit > > > still in a mostly containerized world? > > > > > > > > > Regards, > > > > > > > > > Isha > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > > Van: David Handermann <exceptionfact...@apache.org> > > > > > > Verzonden: woensdag 13 september 2023 15:16 > > > > > > Aan: dev@nifi.apache.org > > > > > > Onderwerp: [DISCUSS] Deprecate TLS Toolkit for Removal? > > > > > > > > > Team, > > > > > > > > > The TLS Toolkit provides a number of useful features for securing NiFi > > > server communication, but it also presents several maintenance > concerns. > > In > > > light of other available tools, I am raising the question of removing > the > > > TLS Toolkit from the repository as part of NiFi 2.0 technical debt > > > reduction. > > > > > > > > > With the addition of automatic self-signed certificate generation in > NiFi > > > 1.14.0, the TLS Toolkit is much less relevant to standalone or > > development > > > deployments. The validity period of the automatic certificate is > limited, > > > but it provides a method of getting started without any need for the > TLS > > > Toolkit. > > > > > > > > > On the other end of the spectrum, orchestrated deployments of > Kubernetes > > > can take advantage of cert-manager [1] for declarative and configurable > > > certificate generation and distribution. > > > > > > > > > Cluster deployments on physical hardware or virtual machines may have > > > organization-specific Certificate Authorities, which require > certificate > > > request processing external to NiFi itself. For this scenario, > > documenting > > > several standard OpenSSL commands may help to describe converting > between > > > PEM and PKCS12 files for common use cases. > > > > > > > > > Back to standalone deployments, Let's Encrypt provides automated > > > certificate provisioning with many tools for managing updates. For a > > > self-signed solution, the mkcert [2] tool is a popular and simple > option > > > that works across modern operating systems. > > > > > > > > > With these alternatives, the use cases for TLS Toolkit seem limited. > > > > > > The Toolkit code is not well-structured, and includes several modes > that > > > involve custom configuration files with a Jetty web server. There are a > > > number of long-standing unresolved Jira issues [3] related to the TLS > > > Toolkit. > > > > > > > > > Removing the TLS Toolkit for NiFi 2.0 would encourage the use of more > > > robust alternatives and keep the project focused on core capabilities. > > > > > > > > > Thoughts? > > > > > > > > > Regards, > > > > > > David Handermann > > > > > > > > > [1] https://cert-manager.io/ > > > > > > [2] https://github.com/FiloSottile/mkcert > > > > > > [3] > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22TLS%20Toolkit%22 > > > > > > > > >
