Hi Aldrin,

 

The machine in question is a linux server that we use as our ‘sandbox’ to try new things (nifi in this case), so I can definitely upgrade the yum package. As for your second question, the server runs on my company’s network, but other than that I don’t see any other considerations. Any thoughts?

 

-Dan

 

From: Aldrin Piri [mailto:aldrinpiri@gmail.com]
Sent: Wednesday, February 01, 2017 5:05 PM
To: users@nifi.apache.org
Subject: Re: GetTwitter - Security/Certificate Issue

 

Hi Dan,

 

I did a bit of poking around and was not able to find that exact RPM version, but was not able to recreate with the CA certs from similar RPMs.  As a quick check, is upgrading the mentioned yum package a possibility on the system?  

 

Are there any intervening network considerations or is the machine in question directly accessing the internet?

 

On Wed, Feb 1, 2017 at 12:35 PM, Dan Giannone <dgiannone@humana.com> wrote:

Hi Aldrin,

 

The version of jdk being used is 1.8. The details of the packages are attached in the PNG files. Please let me know if you need any additional info to help diagnose the issue!

 

Thanks,

 

Dan

 

 

From: Aldrin Piri [mailto:aldrinpiri@gmail.com]
Sent: Tuesday, January 31, 2017 2:20 PM
To: users@nifi.apache.org
Subject: Re: GetTwitter - Security/Certificate Issue

 

Hi Dan,

 

The GetTwitter processor does not make use of an Apache NiFi SSLContextService so the certificate chain issues are likely more tied to the JVM/OS specifically.  Did a quick check on some of the instances I am running and Twitter seems to be operating normally.

 

Could you share some more details about your environment, specifically JRE being used?  If you are running a Linux variant, is your ca-certificates package (Yum based: ca-certificates, Aptitude based: ca-cerificates/ca-certificates-java) up to date?  If so, what version is the package (Yum based: yum info ca-certificates, Aptitude based: apt-cache showpkg ca-certificates)?

 

Thanks,

Aldrin

 

 

On Tue, Jan 31, 2017 at 1:28 PM, Andy LoPresto <alopresto@apache.org> wrote:

Hi Dan,

 

Yes, currently your processor is saying that it receives a certificate identifying https://www.twitter.com (or whatever the actual URL is) but it cannot build a complete chain between the presented certificate and a known CA/trusted certificate. This is because by default, NiFi doesn’t know any trusted certificates. 

 

You can configure a StandardSSLContextService in Controller Services which points the *truststore file* to $JRE_HOME/lib/security/cacerts (for example, on my Mac, it is /Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/jre/lib/security/cacerts), and set the *truststore type* to JKS and the *truststore password* to “changeit”. 

 

There is an existing Jira discussing adding this by default [1], but there are pros and cons to that decision. 

 

 

Andy LoPresto

PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

 

On Jan 31, 2017, at 6:40 AM, Dan Giannone <dgiannone@humana.com> wrote:

 

Hello,

 

I am attempting to configure the GetTwitter processor. I’ve set the required properties such as consumer key and access token. However, when I turn it on I get the following error:

 

Received error CONNECTION_ERROR: sun.security.validator.validatorexception pkix path building failed sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Will attempt to reconnect

 

It’s pretty clear there is some sort of certificate/security issue. How would I go about correcting this?

 

Thanks,

 

Dan Giannone

 


The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

 

 


The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

 


The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.