You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Andrew Grande <ap...@gmail.com> on 2016/06/11 16:14:45 UTC
Standard SSL context always requires keystore/truststore?
Hi,
In my flow I need to hit an external URL over HTTPS (using PostHTTP). The
https endpoint is using standard certificates which have root CA already
bundled in browsers and JVMs.
I'd expect to be able to simply interact with it and rely on bundled JVM
root certs, but it doesn't appear to be the case. The SSLContext CS is
forcing me to configure keystore and truststore.
Any comments? Are my expectations invalid?
Andrew
Re: Standard SSL context always requires keystore/truststore?
Posted by Andy LoPresto <al...@gmail.com>.
I opened NIFI-1477 [1] to address this a little while ago. I am working on a large refactor of the SSL code throughout the application for 1.0 and I am hoping to have an answer for some of these issues.
[1] https://issues.apache.org/jira/browse/NIFI-1477
Andy LoPresto
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Jun 11, 2016, at 10:45, Aldrin Piri <al...@gmail.com> wrote:
>
> Hi Andrew,
>
> Certainly don't disagree that it is confusing for people that come from other environments where this "just works." I don't know we've ever found a path forward that was executed upon. We've grappled with this a few times, one such discussion is [1].
>
> I did a quick search through JIRA, but nothing jumped out at me as being an issue to track this improvement.
>
> Would be interested to see if any of the items in the associated chain seem like a reasonable approach.
>
> [1] http://mail-archives.apache.org/mod_mbox/nifi-users/201509.mbox/browser
>
>> On Sat, Jun 11, 2016 at 12:14 PM, Andrew Grande <ap...@gmail.com> wrote:
>> Hi,
>>
>> In my flow I need to hit an external URL over HTTPS (using PostHTTP). The https endpoint is using standard certificates which have root CA already bundled in browsers and JVMs.
>>
>> I'd expect to be able to simply interact with it and rely on bundled JVM root certs, but it doesn't appear to be the case. The SSLContext CS is forcing me to configure keystore and truststore.
>>
>> Any comments? Are my expectations invalid?
>>
>> Andrew
>
Re: Standard SSL context always requires keystore/truststore?
Posted by Aldrin Piri <al...@gmail.com>.
Hi Andrew,
Certainly don't disagree that it is confusing for people that come from
other environments where this "just works." I don't know we've ever found
a path forward that was executed upon. We've grappled with this a few
times, one such discussion is [1].
I did a quick search through JIRA, but nothing jumped out at me as being an
issue to track this improvement.
Would be interested to see if any of the items in the associated chain seem
like a reasonable approach.
[1] http://mail-archives.apache.org/mod_mbox/nifi-users/201509.mbox/browser
On Sat, Jun 11, 2016 at 12:14 PM, Andrew Grande <ap...@gmail.com> wrote:
> Hi,
>
> In my flow I need to hit an external URL over HTTPS (using PostHTTP). The
> https endpoint is using standard certificates which have root CA already
> bundled in browsers and JVMs.
>
> I'd expect to be able to simply interact with it and rely on bundled JVM
> root certs, but it doesn't appear to be the case. The SSLContext CS is
> forcing me to configure keystore and truststore.
>
> Any comments? Are my expectations invalid?
>
> Andrew
>