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:[email protected]] Sent: Sunday, September 06, 2015 11:38 PM To: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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 >> <[email protected]<mailto:[email protected]>> 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 >>> <[email protected]<mailto:[email protected]>> 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
