Thanks much for the follow up. This thread is definitely going in my
bookmarks!
On Mon, Aug 15, 2022 at 9:37 AM Russell Bateman
wrote:
> If you'll permit, I want to cap this thread I started off a bit by a)
> thanking the many who contributed to it and b) summing up the solution I am
> using
If you'll permit, I want to cap this thread I started off a bit by a)
thanking the many who contributed to it and b) summing up the solution I
am using based on that help.
Here are the command lines and germane instructions. For localhost
below, substitute the DNS name (or, at least,
I found this old thread that may help.
https://lists.apache.org/thread/tg0ddkbyhsp6r5oj9pqc5cg3bo77mnz6
InvokeHTTP in NiFi uses an http client library that has
additional requirements on the SSL certificates presented by remote
servers.
On Tue, Aug 9, 2022 at 10:13 AM Russell Bateman
wrote:
That is an important goal to me as well (giving back as I have been
given to). Last week, I had obligations outside of work that took up
some time.
I have made progress in that (either of the) /SSLContextService/ options
now validates my artifacts, however, I'm not out of the woods yet and
To aid future searches, I wanted to follow up on the mailing list and make
sure you had worked through your problem.
On Tue, Aug 2, 2022 at 3:41 PM Paul Grey wrote:
> Just tried out these (command line) steps; hope they work for you, too.
>
> (1) openssl s_client -connect localhost:8443
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
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
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".
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
>
> 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.
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 wrote:
> I have hesitated between providing some huge tl;dr exposé and something
> shorter. I'll do shorter here.
>
> 0. For now,
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
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
13 matches
Mail list logo
