> > 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. >
This is an old page of mine that may help here. http://htmlpreview.github.io/?https://github.com/greyp9/irby/blob/master/src/main/app/resources/webapp/irby-war/certificate.html I just created an SSL context service using a keystore and truststore created from these instructions, and it enabled fine. --- You mention that you want to use InvokeHTTP in NiFi to access your Tomcat server. Is Tomcat using a CA-signed certificate? If so, you should leave the InvokeHTTP property SSLContextService blank. This will cause InvokeHTTP to use the default JVM truststore, which trusts CA-signed certificates. If you can access your Tomcat from a web browser without certificate warnings, the certificate is likely CA-signed. If Tomcat is using a self-signed certificate, you'll need to assemble a truststore using the self-signed certificate. Download the certificate, and use the instructions above to assemble the truststore. One more bit of information. InvokeHTTP uses an open source library that expects the server hostname to match a distinguished name defined in the certificate. Hope this helps... On Tue, Jul 26, 2022 at 7:35 PM Cannon Palms <[email protected]> wrote: > Hi Russ, > > There is a default Java truststore located at > $JAVA_HOME/lib/security/cacerts that you should use. > > Cannon > > > > On Tue, Jul 26, 2022, 5:50 PM Russell Bateman <[email protected]> > 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 >> >
