You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Paul Grey <gr...@gmail.com> on 2022/08/01 15:26:00 UTC
Re: On configuring SSLContextService...
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 <ru...@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.
>
>
>
Re: On configuring SSLContextService...
Posted by Nathan Gough <th...@apache.org>.
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 <gr...@gmail.com> 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 <ru...@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.
>>
>>
>>
Re: On configuring SSLContextService...
Posted by Paul Grey <gr...@gmail.com>.
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 <ru...@windofkeltia.com>
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 have
> slowed my attack on this problem to deepen my personal understanding and
> knowledge of TLS, key, certificate, keystore, trust store, etc. theory.
>
> At present, with a working *SSLContextService*, I'm investigating the
> following (failure) error back from *InvokeHTTP* when I expected a
> response:
>
> Request Processing failed:
> java.net.ConnectException: Failed to connect to localhost/127.0.0.1:8443
> - Caused by java.net.ConnectException: Connection refused
>
> I believe this is because Tomcat as now configured isn't accepting HTTPS.
>
> I'm engaged in an attempt to understand the whole--generating of the
> self-signed certificate for use by Tomcat, transformation of same into a
> trust store certificate (what you have helped with). I fear that what I
> generated for Tomcat's use, which resides in a keystore referenced from
> *server.xml*, is not correct.
>
> Russ
>
> On 8/9/22 07:28, Paul Grey wrote:
>
> 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 <gr...@gmail.com> wrote:
>
>> 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 <th...@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 <ru...@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 <ru...@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 <
>>>>> russ@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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>
Re: On configuring SSLContextService...
Posted by Russell Bateman <ru...@windofkeltia.com>.
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
have slowed my attack on this problem to deepen my personal
understanding and knowledge of TLS, key, certificate, keystore, trust
store, etc. theory.
At present, with a working /SSLContextService/, I'm investigating the
following (failure) error back from /InvokeHTTP/ when I expected a response:
Request Processing failed:
java.net.ConnectException: Failed to connect to localhost/127.0.0.1:8443
- Caused by java.net.ConnectException: Connection refused
I believe this is because Tomcat as now configured isn't accepting HTTPS.
I'm engaged in an attempt to understand the whole--generating of the
self-signed certificate for use by Tomcat, transformation of same into a
trust store certificate (what you have helped with). I fear that what I
generated for Tomcat's use, which resides in a keystore referenced from
/server.xml/, is not correct.
Russ
On 8/9/22 07:28, Paul Grey wrote:
> 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 <gr...@gmail.com> wrote:
>
> 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 <th...@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
> <ru...@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.
>> 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
>> <ru...@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".
>>>
>>> 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 <http://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
>>> <ru...@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.
>>>
>>
>
Re: On configuring SSLContextService...
Posted by Paul Grey <gr...@gmail.com>.
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 <gr...@gmail.com> wrote:
> 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 <th...@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 <ru...@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 <ru...@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 <ru...@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.
>>>>>
>>>>>
>>>>>
>>>>
>>>
Re: On configuring SSLContextService...
Posted by Paul Grey <gr...@gmail.com>.
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 <th...@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 <ru...@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 <ru...@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 <ru...@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.
>>>>
>>>>
>>>>
>>>
>>
Re: On configuring SSLContextService...
Posted by Nathan Gough <th...@apache.org>.
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 <ru...@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 <ru...@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 <ru...@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.
>>>
>>>
>>>
>>
>
Re: On configuring SSLContextService...
Posted by Russell Bateman <ru...@windofkeltia.com>.
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.
> 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 <ru...@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".
>>
>> 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
>> <http://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
>> <ru...@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.
>>
>
Re: On configuring SSLContextService...
Posted by Paul Grey <gr...@gmail.com>.
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 <ru...@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 <ru...@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.
>>
>>
>>
>
Re: On configuring SSLContextService...
Posted by Russell Bateman <ru...@windofkeltia.com>.
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".
>
> 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 <http://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
> <ru...@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.
>