Support Questions

Find answers, ask questions, and share your expertise

SSLPeerUnverifiedException on InvokeHTTP processor

Explorer

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.

templarian_1-1657135763770.png


3. I am using the self-signed certificate generated by Nifi.

 

Thanks.

1 ACCEPTED SOLUTION

Explorer

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).

View solution in original post

6 REPLIES 6

Master Collaborator

@templarian ,

 

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é

 

--
Was your question answered? Please take some time to click on "Accept as Solution" below this post.
If you find a reply useful, say thanks by clicking on the thumbs up button.

Explorer

Hi @araujo,

 

Just today I detected more than 150 errors over around 400 HTTP request.

Master Guru

@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

Explorer

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.

 

Community Manager

@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,
Community Manager


Was your question answered? Make sure to mark the answer as the accepted solution.
If you find a reply useful, say thanks by clicking on the thumbs up button.
Learn more about the Cloudera Community:

Explorer

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).

Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.