Hi Aldrin, This was with the original package. Also, I’ve attached the verbose output.
Thanks, Dan From: Aldrin Piri [mailto:aldrinp...@gmail.com] Sent: Tuesday, February 07, 2017 5:18 PM To: users@nifi.apache.org Subject: Re: GetTwitter - Security/Certificate Issue Hi Dan, Was this with an updated ca-certificates package or the original one listed when this conversation started? Should have asked from this initially, but could you also please provide the output with verbose logging for the curl command? curl -v https://stream.twitter.com/ --Aldrin On Tue, Feb 7, 2017 at 4:39 PM, Dan Giannone <dgiann...@humana.com<mailto:dgiann...@humana.com>> wrote: Hi Aldrin, Here is a screenshot of the result. Looks like there is definitely an issue. Please let me know if this sheds any light on the issue. Thanks, Dan From: Aldrin Piri [mailto:aldrinp...@gmail.com<mailto:aldrinp...@gmail.com>] Sent: Monday, February 06, 2017 9:07 PM To: users@nifi.apache.org<mailto:users@nifi.apache.org> Subject: Re: GetTwitter - Security/Certificate Issue Hi Dan, Just as a quick diagnostic, are you able to curl https://stream.twitter.com/? This will report in being unauthorized, but will at least confirm that the network connectivity with the associated endpoint used by the processor has appropriate access. I have seen in certain environments that network proxies/filters can attempt to intervene in such requests causing similar errors to manifest. Please let us know your results. --aldrin On Fri, Feb 3, 2017 at 8:32 AM, Dan Giannone <dgiann...@humana.com<mailto:dgiann...@humana.com>> wrote: 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:aldrinp...@gmail.com<mailto:aldrinp...@gmail.com>] Sent: Wednesday, February 01, 2017 5:05 PM To: users@nifi.apache.org<mailto: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 <dgiann...@humana.com<mailto: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<mailto:aldrinp...@gmail.com>] Sent: Tuesday, January 31, 2017 2:20 PM To: users@nifi.apache.org<mailto: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<mailto: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<mailto:alopre...@apache.org> alopresto.apa...@gmail.com<mailto: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<mailto: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. 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.
