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 <dgiann...@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:aldrinp...@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 <alopre...@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. > > > > [1] https://issues.apache.org/jira/browse/NIFI-1477?jql= > text%20~%20%22truststore%22%20AND%20project%20%3D%20%22Apache%20NiFi%22 > <https://issues.apache.org/jira/browse/NIFI-1477?jql=text%20~%20%22truststore%22%20AND%20project%20=%20%22Apache%20NiFi%22> > > > > Andy LoPresto > > alopre...@apache.org > > *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > On Jan 31, 2017, at 6:40 AM, Dan Giannone <dgiann...@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. >
