You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Michael Sharpe <mi...@forefrontnow.com> on 2023/01/04 19:40:31 UTC
PutSplunkHTTP 1.19.1 not working in my NiFi cluster
I had a PutSplunkHTTP 1.18.0 processor (https) working just fine and then I
upgraded to 1.19.1.
I started to get "PKIX path building failed - unable to find valid
certification path to requested target errors".
NiFi properties is set to use a custom truststore.jks file. First I
updated my truststore.jks file to use the Splunk CA. Nothing changed. I
have never added the Splunk CA to my truststore and PutSplunkHTTP 1.18.0
was working.
I then updated my Linux hosts ca-trust with the CA that Splunk is using and
then started seeing "HTTPS hostname wrong: should be <hostname here> Error
during communication with Splunk: {}"
Installed the 1.18.0 Splunk nar and the PutSplunkHTTP processor is working
again with no changes to the processor.
System
NiFi Version 1.19.1
Java Version 11.0.16.1 (Amazon corretto)
CentOS 7 (5 node cluster)
Thanks,
Mike
Re: PutSplunkHTTP 1.19.1 not working in my NiFi cluster
Posted by Michael Sharpe <mi...@forefrontnow.com>.
David,
Thank you for the information. The certificate definitely doesn't match
the hostname in the PutSplunkHTTP (1.19.1) processor. I have asked our
Splunk admin to generate a real certificate with DNS SAM's that I can use.
Thanks,
Mike
On Wed, Jan 4, 2023 at 9:48 PM David Handermann <ex...@apache.org>
wrote:
> Hi Mike,
>
> Thanks for describing the details and comparing the results between NiFi
> versions.
>
> NIFI-10730 [1] released in NiFi 1.19.0 included an upgrade of the Splunk
> client library from 1.6.5.0 to 1.9.1. According to the Splunk Release Notes
> [2] version 1.8.0 of the Splunk client incorporated changes to verify
> server certificates as part of the default configuration. Earlier versions
> of the Splunk client included a permissive verifier implementation, which
> did not perform any checking. This permissive approach is a security
> concern, prompting the change in the default Splunk client behavior.
>
> Updating the ca-trust as you mentioned sounds like it addressed the PKIX
> path error, because the Splunk HttpService relies on the default Java trust
> store. The subsequent hostname matching error seems to indicate that the
> Splunk server certificate does not include a DNS Subject Alternative Name
> that matches the hostname configured in PutSplunkHTTP.
>
> Evaluating the Splunk HttpService, it looks like the SSL Socket Factory is
> configurable, but the configuration applies to all instances of the
> HttpService. This means that supporting for a NiFi SSL Context Service
> could be added, but it would require more significant work to handle socket
> creation properly. Building support for a NiFi SSL Context Service would
> remove the need for updating the Linux ca-trust at the OS level, but it
> would still require a Splunk server certificate with matching hostname.
>
> If you could provide the full stack trace of the error associated with the
> HTTPS hostname error, that might be helpful, but comparing the certificate
> properties against the Hostname setting for PutSplunkHTTP should clarify
> the problem.
>
> Regards,
> David Handermann
>
> [1] https://issues.apache.org/jira/browse/NIFI-10730
> [2]
> https://dev.splunk.com/enterprise/docs/relnotes/relnotes-javasdk/whatsnew/#Version-180
>
> On Wed, Jan 4, 2023 at 1:40 PM Michael Sharpe <
> michael.sharpe@forefrontnow.com> wrote:
>
>> I had a PutSplunkHTTP 1.18.0 processor (https) working just fine and then
>> I upgraded to 1.19.1.
>>
>> I started to get "PKIX path building failed - unable to find valid
>> certification path to requested target errors".
>>
>> NiFi properties is set to use a custom truststore.jks file. First I
>> updated my truststore.jks file to use the Splunk CA. Nothing changed. I
>> have never added the Splunk CA to my truststore and PutSplunkHTTP 1.18.0
>> was working.
>>
>> I then updated my Linux hosts ca-trust with the CA that Splunk is using
>> and then started seeing "HTTPS hostname wrong: should be <hostname here>
>> Error during communication with Splunk: {}"
>>
>> Installed the 1.18.0 Splunk nar and the PutSplunkHTTP processor is
>> working again with no changes to the processor.
>>
>> System
>>
>> NiFi Version 1.19.1
>> Java Version 11.0.16.1 (Amazon corretto)
>> CentOS 7 (5 node cluster)
>>
>> Thanks,
>>
>> Mike
>>
>>
Re: PutSplunkHTTP 1.19.1 not working in my NiFi cluster
Posted by David Handermann <ex...@apache.org>.
Hi Mike,
Thanks for describing the details and comparing the results between NiFi
versions.
NIFI-10730 [1] released in NiFi 1.19.0 included an upgrade of the Splunk
client library from 1.6.5.0 to 1.9.1. According to the Splunk Release Notes
[2] version 1.8.0 of the Splunk client incorporated changes to verify
server certificates as part of the default configuration. Earlier versions
of the Splunk client included a permissive verifier implementation, which
did not perform any checking. This permissive approach is a security
concern, prompting the change in the default Splunk client behavior.
Updating the ca-trust as you mentioned sounds like it addressed the PKIX
path error, because the Splunk HttpService relies on the default Java trust
store. The subsequent hostname matching error seems to indicate that the
Splunk server certificate does not include a DNS Subject Alternative Name
that matches the hostname configured in PutSplunkHTTP.
Evaluating the Splunk HttpService, it looks like the SSL Socket Factory is
configurable, but the configuration applies to all instances of the
HttpService. This means that supporting for a NiFi SSL Context Service
could be added, but it would require more significant work to handle socket
creation properly. Building support for a NiFi SSL Context Service would
remove the need for updating the Linux ca-trust at the OS level, but it
would still require a Splunk server certificate with matching hostname.
If you could provide the full stack trace of the error associated with the
HTTPS hostname error, that might be helpful, but comparing the certificate
properties against the Hostname setting for PutSplunkHTTP should clarify
the problem.
Regards,
David Handermann
[1] https://issues.apache.org/jira/browse/NIFI-10730
[2]
https://dev.splunk.com/enterprise/docs/relnotes/relnotes-javasdk/whatsnew/#Version-180
On Wed, Jan 4, 2023 at 1:40 PM Michael Sharpe <
michael.sharpe@forefrontnow.com> wrote:
> I had a PutSplunkHTTP 1.18.0 processor (https) working just fine and then
> I upgraded to 1.19.1.
>
> I started to get "PKIX path building failed - unable to find valid
> certification path to requested target errors".
>
> NiFi properties is set to use a custom truststore.jks file. First I
> updated my truststore.jks file to use the Splunk CA. Nothing changed. I
> have never added the Splunk CA to my truststore and PutSplunkHTTP 1.18.0
> was working.
>
> I then updated my Linux hosts ca-trust with the CA that Splunk is using
> and then started seeing "HTTPS hostname wrong: should be <hostname here>
> Error during communication with Splunk: {}"
>
> Installed the 1.18.0 Splunk nar and the PutSplunkHTTP processor is working
> again with no changes to the processor.
>
> System
>
> NiFi Version 1.19.1
> Java Version 11.0.16.1 (Amazon corretto)
> CentOS 7 (5 node cluster)
>
> Thanks,
>
> Mike
>
>