nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Taft <a...@adamtaft.com>
Subject Re: GetHTTP processor to consume public https?
Date Mon, 07 Sep 2015 05:38:15 GMT
I'm -1 for providing a standard CA pack with the distribution.  This will
inevitably become out-of-date and someone will need to track it for updates.

Better would be, as Matt Gilman suggested. to have a
"SystemSslContextService" that uses the standard System properties and thus
picks up the JVM default CA configuration.  In this way, a user would
simply have to configure a relatively easy controller service.  It might
look something like:

public class SystemSslContextService implements SslContextService {
  ... // delegate to SSLContext.getDefault() here
}

It would be interesting to discuss if such a controller service should be
enabled by default with any new NiFi installation.  In this way, users
would have a sensible standard SSL context out of the box that enables
GetHTTP to work immediately on public SSL.  Probably a discussing for the
dev list.

Adam


On Sat, Sep 5, 2015 at 11:49 AM, Rick Braddy <rbraddy@softnas.com> wrote:

> Recommend we consider including a standard CA cert pack and ship it with
> NiFi, much like the browsers do, so basic SSL access is easy by default.
>
> One thing that will help with these kinds of decisions is to decide who
> the target users are intended to be for NiFi for a given release.
>
> If it's primarily Java developers and OEM customers, then ignore the above
> suggestion, as we can read the docs and pay the vig to get ramped up like
> everyone.
>
> If it's the average Linux admin, then it's borderline as admins are very
> time pressed and would prefer a working solution with little configuration
> for common tasks.
>
> If it's non-IT and non-developers, then these kinds of technical hurdles
> must be resolved for a successful solution out of the box.
>
> My 2c.
> Rick
>
>
>
> On Sep 5, 2015, at 9:14 AM, Aldrin Piri <aldrinpiri@gmail.com> wrote:
>
> I think we can give documentation about where such items are located and
> help users along who aren't familiar with these nuances.
>
> The "auto suggest" could be nice but would be curious how this would
> manifest itself in UX.
> On Sat, Sep 5, 2015 at 07:35 Matt Gilman <matt.c.gilman@gmail.com> wrote:
>
>> Chris,
>>
>> Assuming it's one way ssl, did you try configuring an SslContextService
>> with the cacerts file that comes bundled in with your Java install? The
>> trust store should be located somewhere in your Java installation. Maybe
>> JAVA_HOME/jre/lib/security/cacerts assuming it's a JDK. The default
>> password is usually changeit.
>>
>> Let me know if that helps.
>>
>> Matt
>>
>> Sent from my iPhone
>>
>> On Sep 5, 2015, at 2:53 AM, Chris Teoh <chris.teoh@gmail.com> wrote:
>>
>> I think that makes sense. I don't know how Python does it but using that
>> was very easy. I'm not familiar with having to generate a keystore or trust
>> store or both (which one do I use?) to get at public SSL sites. Perhaps
>> document how to do it if it was a self signed or internally signed
>> certificate but ideally it should be easy for public internet sites.
>> On Sat, 5 Sep 2015 at 2:31 pm Joe Witt <joe.witt@gmail.com> wrote:
>>
>>> would it be feasible to try and look for reasonable default locations
>>> to find prebuilt keystores to make this sort of thing easier?
>>>
>>> ...in addition to documenting it of course.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Fri, Sep 4, 2015 at 9:10 PM, Aldrin Piri <aldrinpiri@gmail.com>
>>> wrote:
>>> > The issue for those sites is you need a set of root certificates for
>>> the
>>> > common sites on the web much the same way a browser comes bundled with
>>> them.
>>> >
>>> > The Linux distributions typically come with a prebuilt truststore when
>>> Java
>>> > is installed and it lives within /etc/pki/. Exact location escapes me
>>> at the
>>> > moment. If you are in another environment, let us know and we can try
>>> to
>>> > help get you setup there.
>>> >
>>> > Several people run into this because that one-way SSL is one of those
>>> things
>>> > that just works (or is bypassed/ignored when it is not). Not sure if we
>>> > should have a processor equivalent to a curl -k param (gut feel is a
>>> no),
>>> > but this is at least FAQ material.
>>> >
>>> > On Fri, Sep 4, 2015 at 23:44 Chris Teoh <chris.teoh@gmail.com> wrote:
>>> >>
>>> >> Hmm sorry I'm not sure. I just want to do a GET request from a site
>>> that
>>> >> returns me JSON like I would using a web browser or a Python script
>>> where
>>> >> I'm guessing the certificate side of things are already working.
>>> >> On Sat, 5 Sep 2015 at 1:41 pm Joe Witt <joe.witt@gmail.com> wrote:
>>> >>>
>>> >>> Chris,
>>> >>>
>>> >>> It's quite common to interact with SSL services using 1-way or 2-way
>>> >>> SSL.  Are you just wanting to hit something with 1-way SSL?  What
>>> >>> happens when you try it?
>>> >>>
>>> >>> Thanks
>>> >>> Joe
>>> >>>
>>> >>> On Wed, Sep 2, 2015 at 3:32 PM, Chris Teoh <chris.teoh@gmail.com>
>>> wrote:
>>> >>> > Hi,
>>> >>> >
>>> >>> > I'm still a little lost on how to do a GET on ssl sites. The
>>> standard
>>> >>> > ssl
>>> >>> > context controller configuration is baffling. Is there anyone
that
>>> has
>>> >>> > done
>>> >>> > this? I'm trying to consume public internet ssl site.
>>> >>> >
>>> >>> > Kind regards
>>> >>> > Chris
>>>
>>

Mime
View raw message