Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Fri, 17 Jul 2015 07:36:04 +0000 (UTC)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.12843858.1436447215000.212615.1437118564644@Atlassian.JIRA>
In-Reply-To: <JIRA.12843858.1436447215000@Atlassian.JIRA>
References: <JIRA.12843858.1436447215000@Atlassian.JIRA>
 <JIRA.12843858.1436447215483@arcas>
Subject: [jira] [Updated] (CAMEL-8946) Original SSLHandshakeException was
 overridden by Camel Netty Http producer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CAMEL-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-8946:
-------------------------------
    Fix Version/s: 2.16.0

> Original SSLHandshakeException was overridden by Camel Netty Http producer
> --------------------------------------------------------------------------
>
>                 Key: CAMEL-8946
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8946
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-netty, camel-netty-http
>    Affects Versions: 2.12.5
>            Reporter: Joe Qiang Luo
>             Fix For: 2.16.0
>
>         Attachments: NettyHttpSSLHandshakeErrorTest.java, client-keystore.jks, client-truststore.jks, patch.txt, server-keystore.jks, server-truststore.jks
>
>
> I am having difficulties to troubleshoot some of the SSL failures when my application attempts to connect to back ends. I am not able to understand by looking at the logs what is making the connection to fail.
> When inspecting the behavior of 'camel-netty-http' for a particular use case where no trusted certificates are available, I realize that Netty is throwing an SSLHandshakeException, but then it gets lost and a ClosedChannelExcetpion is thrown back instead.
> While DEBUG and WARN level messages give indication about the real source of the problem, the final ERROR level message looses the error context. This is problematic when I run the system in ERROR level, and when I see failures I can't determine the reasons.
> The sequence of logs is as follows:
> 1) first a DEBUG trace:
> DEBUG Closing channel as an exception was thrown from Netty
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> ... Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> ... Caused by: sun.security.validator.ValidatorException: No trusted certificate found
> 2) then a WARN trace:
> WARN  HttpServerChannelHandler is not found as attachment to handle exception, send 404 back to the client.
> javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
> 3) and an ERROR trace:
> ERROR Failed delivery for...
> ... java.nio.channels.ClosedChannelException
> 	at org.jboss.netty.handler.ssl.SslHandler$7.run(SslHandler.java:1766)
> I have made a simple fix on NettyProducer.java class since NettyHttpProducer class is inherited from it.
> I'll also attach a junit test
> org/apache/camel/component/netty/http/NettyHttpSSLHandshakeErrorTest.java
> that reproduces the situation as well as a patch (patch.txt) to this JIRA.
>  
> Note, the junit test requires some keystore files so you will need to copy over following four files:
> camel-cxf/src/test/resources/wssecurity/keystore/client-keystore.jks
> camel-cxf/src/test/resources/wssecurity/keystore/client-truststore.jks
> camel-cxf/src/test/resources/wssecurity/keystore/server-keystore.jks
> camel-cxf/src/test/resources/wssecurity/keystore/server-truststore.jks
> over to camel-netty-http/src/test/resources/jsse/ folder in order to get the junit test to work.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)