You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Chris Teoh <ch...@gmail.com> on 2015/09/03 00:32:31 UTC
GetHTTP processor to consume public https?
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
RE: GetHTTP processor to consume public https?
Posted by Rick Braddy <rb...@softnas.com>.
I agree with Adam and Matt – should pick up JVM default CA configuration by default so HTTPS/SSL works out of the box.
From: Adam Taft [mailto:adam@adamtaft.com]
Sent: Sunday, September 06, 2015 11:38 PM
To: users@nifi.apache.org
Subject: Re: GetHTTP processor to consume public https?
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 <rb...@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 <al...@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 <ma...@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 <ch...@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 <jo...@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 <al...@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 <ch...@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 <jo...@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 <ch...@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
Re: GetHTTP processor to consume public https?
Posted by Adam Taft <ad...@adamtaft.com>.
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 <rb...@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 <al...@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 <ma...@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 <ch...@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 <jo...@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 <al...@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 <ch...@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 <jo...@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 <ch...@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
>>>
>>
Re: GetHTTP processor to consume public https?
Posted by Rick Braddy <rb...@softnas.com>.
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 <al...@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 <ma...@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 <ch...@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 <jo...@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 <al...@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 <ch...@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 <jo...@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 <ch...@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
Re: GetHTTP processor to consume public https?
Posted by Aldrin Piri <al...@gmail.com>.
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 <ma...@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 <ch...@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 <jo...@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 <al...@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 <ch...@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 <jo...@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 <ch...@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
>>
>
Re: GetHTTP processor to consume public https?
Posted by Matt Gilman <ma...@gmail.com>.
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 <ch...@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 <jo...@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 <al...@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 <ch...@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 <jo...@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 <ch...@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
Re: GetHTTP processor to consume public https?
Posted by Chris Teoh <ch...@gmail.com>.
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 <jo...@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 <al...@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 <ch...@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 <jo...@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 <ch...@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
>
Re: GetHTTP processor to consume public https?
Posted by Joe Witt <jo...@gmail.com>.
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 <al...@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 <ch...@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 <jo...@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 <ch...@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
Re: GetHTTP processor to consume public https?
Posted by Aldrin Piri <al...@gmail.com>.
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 <ch...@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 <jo...@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 <ch...@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
>>
>
Re: GetHTTP processor to consume public https?
Posted by Chris Teoh <ch...@gmail.com>.
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 <jo...@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 <ch...@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
>
Re: GetHTTP processor to consume public https?
Posted by Joe Witt <jo...@gmail.com>.
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 <ch...@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