Hi all,
a Cdata JDBC driver for enabling Splunk connection on KNIME is currently being tested. The driver was added at the path File > Preferences > KNIME > Databases and with the support of IT for firewall settings, the connection is apparently in place.
An ad hoc Database connector was set up for testing the driver, which according to Cdata should let us query Splunk using SQL and this is what we would like to test.
- Database driver: cdata.jdbc.splunk.SplunkDriver
- Database URL: jdbc:splunk:URL=https://datahub.mycompany.zone:8089
The database connector feeds a Database reader with a very simple SQL test query (SELECT TOP 10 customer_id FROM tablexyz).
However the query fails after running for a few minutes, returning the following error message: ERROR Database Reader 0:3 Execute failed: (“pjc”):
The error message was googled but nothing specific was retrieved about that.
After talking to Cdata and my company’s IT department, a possible cause of the problem might be tied to Splunk datahub SSL certificate, which is a self-signed one. Is there an option for KNIME to ignore self-signed certificates?
Hope somebody can help with this.
Thanks a lot in advance, best regards
SA
Hi @SalvoAbbru
You could try to add the certificate to the Java Truststore with the keytool (https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html)
Maybe the KNIME.log will provide a little more info about the problem. You can find it in at “View”->“Open KNIME log”. You can send it to me via private message so I can have a look into it too.
Best regards Mareike
Hi @mareike.hoeger,
many thanks for your reply.
I successfully managed to add the certificate as recommended, however I get a new error now:
ERROR Database Reader 0:3 Execute failed: Cannot conclude ssl handshake. Cause: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
Any idea? 
Kind regards,
Salvatore
Hi,
that looks for me like an intermediate certificate is missing which breaks the key chain.
Did you take a look into the knime.log before you tried the certificate? It is still not clear, whether the initial problem was caused by the certificate anyway, or is it?
best regards Mareike
Hi @mareike.hoeger,
ok, I’ll summarize the last steps before I posted on KNIME.
Cdata, the driver provider, was sent a Splunk database connector log file and looking at it they concluded the problem was due to the fact their driver didn’t get a response when querying the API.
I reported this fact to my IT department and they tried querying the API by copying/pasting the relevant URL in a browser. They got a 2 MB response. At this point they hint the problem might be due to Splunk datahub certificate, which is a self-signed one and maybe KNIME doesn’t like that. IT added that rather than replacing that certificate, they’d be more up for trying a way and see if KNIME can ignore self-signed certificates.
Then I opened the issue on the forum and you recommended to add the Splunk self-signed certificate in my cacerts Java Truststore (successfully done under my JRE PC path /lib/security/cacerts). Nevertheless, it seems like that was ineffective - reconnecting now to my yesterday last post.
This is how the Splunk log file looks like soon after I try and run a test query:
As you can see, the log files says the Server cert wasn’t accepted. This is a different certificate than the self-signed one I added yesterday as you told me. Should I save this certificate and add it to the Java Truststore as well? Or the problem is different?
Hope it helps!
Thanks,
Salvatore
Hey,
well no is not a different problem, that is what I assumed: one other of the certificates in the chain is missing. If you also trust this certificate I would add it to the Truststore as well.
I see your journey. I am just not sure whether the idea with the certificate is the actual problem (The inital error message in the console is not the most informative one), but we will find out once the trust chain is valid. 
best regards Mareike
Yeah I agree, that “pjc” error could hardly be more enigmatic…
