Just tried out these (command line) steps; hope they work for you, too. (1) openssl s_client -connect localhost:8443 -showcerts This will dump a bunch of text to stdout. You want to grab the text between these two text lines: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ... and save that text to a file "trust.cer".
(2) openssl x509 -in trust.cer -text This will verify that you got the right text. (3) keytool -importcert -keystore trust.jks -file trust.cer -alias 1 This will create a JKS keystore that contains your certificate. The command will ask for a password (twice to confirm); pick something easy. (4) Enter "Truststore Filename" (/full/path/to/trust.jks) , "Truststore Password", and "Truststore Type" (JKS) into your StandardSSLContextService properties. Cheers! On Tue, Aug 2, 2022 at 11:33 AM Nathan Gough <thena...@apache.org> wrote: > That's right Russ, if you purchased a commercially signed certificate, > InvokeHTTP should work by default. With your self signed certificate, you > will need an SSL context service, and I believe you will need to insert the > self signed certificate into the trust store. I suggest using > KeystoreExplorer to create a trust store, import the self signed > certificate, save that trust store file and then point to that file in the > SSL context service. Let us know if you have issues with that part. > > The screenshot error message you sent is showing that InvokeHTTP does not > trust the remote server when it says 'unable to find valid certfiication > path to requested target' (a pretty confusing error in my opinion). > > X509 key/certs and key/trust store stuff is pretty tricky to understand > the first time around. > > Nathan > > > On Tue, Aug 2, 2022, 11:00 AM Russell Bateman <r...@windofkeltia.com> > wrote: > >> Yes, of course. And, therefore, *SSLContextService* is required was my >> conclusion. I see the point more clearly now, but my conclusion seems >> inescapable. To forego *SSLContextService* we would have to purchase a >> commercially signed certificate for use by Tomcat, right? >> >> I will experiment with just somehow injecting the self-signed certificate >> we created into the trust store certificate? --which I thought I had done >> already, but *SSLContextService* has steadfastly refused to accept >> anything I throw at it. (I reiterate that this is my first TLS rodeo; I >> have never had to do this kind of work before. I greatly appreciate your >> patience.) >> >> Russ >> >> On 8/1/22 19:03, Paul Grey wrote: >> >> 1. You've instructed your browser to accept the (untrusted) certificate >> that is being presented by Tomcat. >> [image: untrusted.cert.png] >> >> 2. You've supplied the "--insecure" flag to curl. >> https://curl.se/docs/manpage.html#-k >> >> 3. The NiFi equivalent to these two instructions is to provide a >> truststore, which contains a record specifying the certificate being served >> by your Tomcat server. >> >> >> On Mon, Aug 1, 2022 at 6:27 PM Russell Bateman <r...@windofkeltia.com> >> wrote: >> >>> >>> Okay. I'm hoping this is true, but it's not what I'm seeing. It's not >>> dawning on me yet what I'm doing wrong. >>> >>> 1. If I hit my service from a browser, >>> https://localhost:8443/mdht-restlet, I get its splash page. >>> 2. If I curl the splash page, I get it: >>> russ@tirion ~/sandboxes/mdht-restlet/src/test/resources/fodder/gold $ >>> curl --insecure --request GET https://localhost:8443/mdht-restlet >>> --header 'Accept: text/plain' >>> HL7v3 CDA on-demand generation service using Model-driven Health Tools >>> (MDHT). The generator is up. >>> >>> Manifest-Version: 1.0 >>> Implementation-Title: mdht-restlet >>> Implementation-Version: 3.3.10-2 >>> Specification-Title: mdht-restlet >>> ... >>> >>> 2. However, if I try *InvokeHTTP* to POST, I get this: ( >>> https://www.javahotchocolate.com/notes/nifi-images/invokehttp-error.png) >>> >>> >>> >>> >>> On 8/1/22 09:26, Paul Grey wrote: >>> >>> I just checked a running NiFi, built locally from the main branch. I >>> configured an InvokeHTTP processor to perform a GET request to " >>> https://www.google.com/";. No "SSL Context Service" was configured. >>> >>> The request completed successfully, routing output to relationships >>> "RESPONSE" and "ORIGINAL". >>> >>> [image: InvokeHTTP-google.png] >>> >>> I would expect the same behavior on your NiFi instance. If no >>> SSLContextService is supplied, the expectation is that the default JVM >>> truststore is used, and the "google.com" certificate is signed by a CA >>> trusted by the default truststore. If this test case does not work for >>> you, I would verify the validity of the default truststore. Another check >>> would be to perform this same test on a different machine running NiFi. >>> >>> >>> On Fri, Jul 29, 2022 at 10:28 AM Russell Bateman <r...@windofkeltia.com> >>> wrote: >>> >>>> Just a note (for later readers of this thread)... >>>> >>>> My experience now with this trick seems to say that, as long as "https" >>>> is in the URL, a *SSLContextService* must be supplied. As a URL with >>>> "https" and port number 8443 is the only way I have to engage TLS at the >>>> far end, I must live with *SSLContextService*'s requirements. >>>> >>>> On 7/26/22 19:17, Paul Grey wrote: >>>> >>>> leave the InvokeHTTP property SSLContextService blank. >>>> >>>> >>>> >>> >>
