Created on 07-06-2022 12:38 PM - edited 07-06-2022 12:40 PM
Hi,
I am very frequently getting the following exception whenever I call the URL seen in the message.
2022-07-06 15:24:56,138 ERROR [Timer-Driven Process Thread-10] o.a.nifi.processors.standard.InvokeHTTP InvokeHTTP[id=33351c02-15ee-1ccc-6c00-dda0e16110ca] Routing to Failure due to exception: javax.net.ssl.SSLPeerUnverifiedException: Hostname creatorapp.zoho.com not verified (no certificates): javax.net.ssl.SSLPeerUnverifiedException: Hostname creatorapp.zoho.com not verified (no certificates)
javax.net.ssl.SSLPeerUnverifiedException: Hostname creatorapp.zoho.com not verified (no certificates)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:396)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
at org.apache.nifi.processors.standard.InvokeHTTP.onTrigger(InvokeHTTP.java:850)
at org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
at org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1202)
at org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:214)
at org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:103)
at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Some details about it:
1. The URL certificate is valid
2. The request is processed correctly on the second or third try and if several flowfiles are queued, the following messages may or may not present the same behavior. But usually the request is always processed.
3. I am using the self-signed certificate generated by Nifi.
Thanks.
Created 07-22-2022 08:59 AM
Hi All,
The problem was on the JDK version. We were using OpenJDK 11.0.2 which had a bug in the TLS handshake.
Solution: Upgrade JDK (now using 11.0.15).
Created 07-06-2022 04:40 PM
That's odd. It looks like the server sometimes fails to provide the right certificate to the client.
How often does this happen?
Cheers,
André
Created 07-12-2022 05:44 PM
Created 07-07-2022 08:41 AM
@templarian
Does the target URL hostname go to a LB that can route that request to any number of endpoint servers?
Perhaps not all those endpoint servers use the same serverAuth certificate or are not all signed by the same authority or an authority known the the truststore configured in the SSLContextService you have configured in your invokeHTTP processor.
In this scenario, it would work when your request get send to some endpoints and fail with others even though what you have configured in the processor never changes.
If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post.
Thank you,
Matt
Created 07-12-2022 06:44 PM
Does the target URL hostname go to a LB that can route that request to any number of endpoint servers?
I don't really know, but thing that this is the scenario.
Perhaps not all those endpoint servers use the same serverAuth certificate or are not all signed by the same authority or an authority known the the truststore configured in the SSLContextService you have configured in your invokeHTTP processor.
Is possible. I added the root certificate available on CA Authority to the keystore and will monitor the behavior.
Created 07-10-2022 10:41 PM
@templarian, Have any of the replies helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.
Regards,
Vidya Sargur,Created 07-22-2022 08:59 AM
Hi All,
The problem was on the JDK version. We were using OpenJDK 11.0.2 which had a bug in the TLS handshake.
Solution: Upgrade JDK (now using 11.0.15).