It's not a NiFi issue; it's a PKI infrastructure thing.
For PKI, you always need a truststore and a keystore. You can have them
reside in the same place (not recommended) and/or you could just trust
everything (again, not recommended), and/or your app (eg: Tomcat) could
be default configured so that is does the risky "not recommended" things
mentioned above. But that doesn't mean that "no trust store is needed
or involved".
There are some good tutorials out there for using keytool and openssl
for setting up PKI for client/server 2-way authentication.
Pat
--
Patrick Timmins
Datasate Technical
https://www.linkedin.com/in/patrick-timmins/
On 7/26/2022 4:50 PM, Russell Bateman wrote:
I have hesitated between providing some huge tl;dr exposé and
something shorter. I'll do shorter here.
0. For now, I'm using "changeit" below as password rolling a
self-signed certificate for key, key store and trust store.
1. I have a service running in Tomcat that I hit via HTTPs because the
content always involves personal health information.
2. I use a key store containing my certificate. No trust store is
needed or involved in Tomcat.
3. I need to hit my Tomcat service using /InvokeHTTP/ in my flow.
4. This means configuring an instance of
/Standard[Restricted]SSLContextService/.
5. The SSL context service insists on a defined key store with key
password and key store password.
6. The SSL context service insists on a defined trust store. The best
I have been able to do is to roll the key store certificate into a
trust store.
7. When either key- or trust store file is missing, the SSL context
service complains that a resource is missing (for key store or trust
store).
8. Once both files/resources exist, all three passwords appear crucial.
9. Despite password used to create key and certificates, it is always
wrong according to SSL context service validator which consistently
issues:
/Keystore Properties is invalid because invalid keystore password
or type specified for file __________.//
//Truststore Properties is invalid because invalid truststore
password or type specified for file __________./
It would be nice to see a step-by-step illustration of creating the
key, key store and trust store artifacts required by SSL context
service and perhaps the full configuration of the SSL context service.
Other notes:
1. I seem to get pretty far toward a solution using Java's keytool.
2. I don't get very far using openssl.
3. I get even less traction trying to use NiFi's TLS toolkit to solve
this.
4. I guess I could simply write my own SSL context service that
doesn't require a trust store?
Huge thanks for any help or comments.
Russ
P.S. I have a scratch sheet that reveals how I created artifacts and
thought through the problem at:
https://www.javahotchocolate.com/notes/keytool-experience.html
