Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

java.security.cert.CertificationException in Nifi's InvokeHTTP

java.security.cert.CertificationException in Nifi's InvokeHTTP

Contributor

I'm running a simple flow on dockerized Nifi 1.1.1 which uses InvokeHTTP processor to load data from a https data source.

I have setup a StandardSSLContextService where the keystore filename (/etc/ssl/certs/java/cacerts), password (the default 'changeme'), and type (JKS) is defined.

The flow works if I use GetHTTP processor (and https endpoint), but when I switch to InvokeHTTP the following exception is thrown:

2017-02-13 08:48:44,748 ERROR [Timer-Driven Process Thread-7] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=3352601e-015a-1000-20c6-39e7d9786866] Routing to Failure due to exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
2017-02-13 08:48:44,749 ERROR [Timer-Driven Process Thread-7] o.a.nifi.processors.standard.InvokeHTTP
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_111]
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949) ~[na:1.8.0_111]
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ~[na:1.8.0_111]
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) ~[na:1.8.0_111]
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509) ~[na:1.8.0_111]
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) ~[na:1.8.0_111]
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) ~[na:1.8.0_111]
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) ~[na:1.8.0_111]
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) ~[na:1.8.0_111]
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) ~[na:1.8.0_111]
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) ~[na:1.8.0_111]
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387) ~[na:1.8.0_111]
	at com.squareup.okhttp.internal.io.RealConnection.connectTls(RealConnection.java:188) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.io.RealConnection.connectSocket(RealConnection.java:145) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.io.RealConnection.connect(RealConnection.java:108) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.http.StreamAllocation.findConnection(StreamAllocation.java:184) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:126) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.http.StreamAllocation.newStream(StreamAllocation.java:95) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:283) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:224) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.Call.getResponse(Call.java:286) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:243) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:205) ~[okhttp-2.7.1.jar:na]
	at com.squareup.okhttp.Call.execute(Call.java:80) ~[okhttp-2.7.1.jar:na]
	at org.apache.nifi.processors.standard.InvokeHTTP.onTrigger(InvokeHTTP.java:624) ~[nifi-standard-processors-1.1.1.jar:1.1.1]
	at org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27) [nifi-api-1.1.1.jar:1.1.1]
	at org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099) [nifi-framework-core-1.1.1.jar:1.1.1]
	at org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) [nifi-framework-core-1.1.1.jar:1.1.1]
	at org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) [nifi-framework-core-1.1.1.jar:1.1.1]
	at org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132) [nifi-framework-core-1.1.1.jar:1.1.1]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_111]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_111]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_111]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_111]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_111]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_111]
	at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
	at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(SSLContextImpl.java:1119) ~[na:1.8.0_111]
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491) ~[na:1.8.0_111]
	... 32 common frames omitted

The same flow works well if I run it natively under OS X.

Any idea / help is greatly appreciated!

1 REPLY 1

Re: java.security.cert.CertificationException in Nifi's InvokeHTTP

In general you need to populate the truststore of the StandardSSLContextService to interact with remote HTTPS endpoints. Populating the keystore provides the certificates used to identify the NiFi service and the private keys used to sign (and decrypt) data by NiFi. Configuring the truststore (and pointing it to cacerts as you did) allows NiFi to verify the public key certificate chain presented by the remote endpoint. Can you try populating the truststore values and re-try your flow? I am not sure why this would work natively on your OS X machine, as there is an existing open Jira to provide this "out-of-the-box" functionality (and it is noted there that InvokeHTTP works without custom StandardSSLContextService creation while GetHTTP requires it).