Agreed with Paul, InvokeHTTP will work without setting an SSLContextService if the URL you're accessing has a certificate from the generally accepted certificate authorities like Verisign etc.
I'm a bit late to the party, but I also do not see that the SSLContextService requires both a key and trust store. It requires one or the other, or both. You can set only a truststore and it will enable just fine. If your remote server does not require a client certificate to be presented, then all you would need to set is the truststore. I would recommend in future trying out a GUI tool called KeystoreExplorer ( https://keystore-explorer.org). It removes a lot of the overhead of figuring out Java's keytool commands and generating certificates and stores. It won't do all the work for you, you'll still need to understand some PKI details but it definitely removes some of the burden. In summary, the SSLContextService is going to be required for accessing private HTTPS URLs that are signed by your own X509 infrastructure. - In cases of public websites/APIs, you can probably use Java's cacerts which as Paul stated is provided by default and does not need to be set. To manually set this, it's located at $JAVA_HOME/lib/security/cacerts as Cannon mentioned and it would be set in the 'Truststore' parameters of the SSLContextService. - In cases of private websites/APIs with internally generated certificates, you will probably need to download the remote server's certificate authority and store it in a truststore, and configure the 'Truststore' parameters of the SSLContextService. - In cases of mutual/two-way authentication with private websites/APIs, you will need to populate both the 'Keystore' and 'Truststore' parameters of the SSLContextService with a client certificate signed by the same CA in the keystore and the CA itself in the truststore. Nathan On Mon, Aug 1, 2022 at 11:26 AM Paul Grey <[email protected]> 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 <[email protected]> > 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. >> >> >>
