Member since
10-16-2018
4
Posts
0
Kudos Received
0
Solutions
10-23-2018
05:54 PM
A newer version JRE fixed the above problem. It all seems to be working.
... View more
10-20-2018
01:51 AM
I seem to have hit a brick wall. It seems the NiFi HTTP processors (InvokeHTTP and GetHTTP) are not happy with wildcard certificates. Meaning, if a CA issues a common name cert like the below * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: * subject: CN=*.weathersource.com,OU=PositiveSSL Wildcard,OU=Domain Control Validated * start date: Aug 15 00:00:00 2018 GMT * expire date: Aug 24 23:59:59 2020 GMT * common name: *.weathersource.com The processors wont work.
Here is the errors that are thrown. 2018-10-19 16:59:29,190 ERROR [Timer-Driven Process Thread-1] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=8cfcd96c-0166-1000-ea61-261c1a449c0e] Yielding processor due to exception encountered as a source processor: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure: {}
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.k.a(k.java:15)
at com.ibm.jsse2.k.a(k.java:23)
at com.ibm.jsse2.av.b(av.java:343)
at com.ibm.jsse2.av.a(av.java:981)
at com.ibm.jsse2.av.i(av.java:869)
at com.ibm.jsse2.av.a(av.java:19)
at com.ibm.jsse2.av.startHandshake(av.java:672)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:281)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:251)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:151)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:195)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:121)
at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:100)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:185)
at okhttp3.RealCall.execute(RealCall.java:69)
at org.apache.nifi.processors.standard.InvokeHTTP.onTrigger(InvokeHTTP.java:791)
at org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
at org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1165)
at org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:203)
at org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:319)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:191)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.lang.Thread.run(Thread.java:811) NiFi should have used more of the host OS's environment to handle these things. Industry standard tools, like curl, have no issues.
Am I missing something? Do I need to write custom processors for simple HTTP GET/POSTS because NiFi isnt friendly with enterprise environments? IMO, NiFi is trying to be its own monolythic environment but it should utilize more of the underlying host OS to get around these corporate specific problems. Erik
... View more
10-17-2018
05:11 PM
keytool error (likely untranslated): java.io.IOException: Invalid keystore format The format of the /usr/share/pki/ca-trust-source/ca-bundle.trust.crt Is not compatible with any keystore formats. ca-bundle.trust.crt format is some openssl specific format, not java keystore. ca-bundle.trust.crt is a mash of 200 keys. I think it requires some manipulation with openssl first. Even if I use openssl it will only grab 1 key of the 200 keys.
... View more
10-16-2018
04:22 PM
I am setting up NiFi to be able to fetch data from public websites using HTTPS. This is a very painful process because of the keystore. The host OS has all of the certificates of authority in 1 file. /usr/share/pki/ca-trust-source/ca-bundle.trust.crt Its a massive file of all of the public certificates of authority. How do I import that 1 very large file into the keystore? I have our own internal self-signed CA successfully working with keystore+nifi but not the standard public CA's.
... View more
Labels:
- Labels:
-
Apache NiFi