Return-Path: <issues-return-38080-archive-asf-public=cust-asf.ponee.io@camel.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id D2351200BE7
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Tue, 20 Dec 2016 20:54:00 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id D0C1A160B12; Tue, 20 Dec 2016 19:54:00 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 2D4F7160B33
	for <archive-asf-public@cust-asf.ponee.io>; Tue, 20 Dec 2016 20:54:00 +0100 (CET)
Received: (qmail 77709 invoked by uid 500); 20 Dec 2016 19:53:59 -0000
Mailing-List: contact issues-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@camel.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@camel.apache.org>
List-Post: <mailto:issues@camel.apache.org>
List-Id: <issues.camel.apache.org>
Reply-To: dev@camel.apache.org
Delivered-To: mailing list issues@camel.apache.org
Received: (qmail 77433 invoked by uid 99); 20 Dec 2016 19:53:59 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Dec 2016 19:53:59 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id A41C72C0453
	for <issues@camel.apache.org>; Tue, 20 Dec 2016 19:53:58 +0000 (UTC)
Date: Tue, 20 Dec 2016 19:53:58 +0000 (UTC)
From: "Joe Luo (JIRA)" <jira@apache.org>
To: issues@camel.apache.org
Message-ID: <JIRA.13029547.1482263566000.565805.1482263638669@Atlassian.JIRA>
In-Reply-To: <JIRA.13029547.1482263566000@Atlassian.JIRA>
References: <JIRA.13029547.1482263566000@Atlassian.JIRA> <JIRA.13029547.1482263566326@arcas>
Subject: [jira] [Updated] (CAMEL-10628) camel jetty9 endpoint configured
 with sslContextParametersRef and jetty handlers causes SSL handshake
 failure
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Tue, 20 Dec 2016 19:54:01 -0000


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

Joe Luo updated CAMEL-10628:
----------------------------
    Attachment: patch.txt

> camel jetty9 endpoint configured with sslContextParametersRef and jetty handlers causes SSL handshake failure
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-10628
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10628
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jetty
>    Affects Versions: 2.17.0
>            Reporter: Joe Luo
>         Attachments: patch.txt
>
>
> I have a camel route using Rest DSL with Jetty component:
> {code}
> <camelContext id="camel" trace="true" streamCache="true" xmlns="http://camel.apache.org/schema/blueprint">
>       <restConfiguration component="jetty" bindingMode="off" scheme="https" host="localhost" port="9080" contextPath="/">
>         <endpointProperty key="sslContextParametersRef" value="sslContextParameter"/>
>         <endpointProperty key="handlers" value="#securityHandler"/>
>         <endpointProperty key="matchOnUriPrefix" value="true"/>
>       </restConfiguration>
>       <rest path="/customerservice">
>           <get uri="/customers" >
>               <to uri="direct:processGet"/>
>           </get>
>           <get uri="/customers/{id}" >
>               <to uri="direct:processGet"/>
>           </get>
>           <post uri="/customers" consumes="application/json" produces="application/json">
>               <to uri="direct:processPost"/>
>           </post>
>       </rest>
> {code}
> The underlying camel jetty component is configured with sslContextParametersRef and a Jetty Handler org.eclipse.jetty.security.ConstraintSecurityHandler to enforce SecurityConstraints on the Jetty endpoint. 
> If I remove the Jetty ConstraintSecurityHandler, it works fine, for instance:
> {code}
> <camelContext id="camel" trace="true" streamCache="true" xmlns="http://camel.apache.org/schema/blueprint">
>       <restConfiguration component="jetty" bindingMode="off" scheme="https" host="localhost" port="9080" contextPath="/">
>         <endpointProperty key="sslContextParametersRef" value="sslContextParameter"/>
>         <!--endpointProperty key="handlers" value="#securityHandler"/-->
>         <endpointProperty key="matchOnUriPrefix" value="true"/>
>       </restConfiguration>
> {code}
> But when I add the Jetty ConstraintSecurityHandler back to the camel Rest DSL, I am getting following error:
> {code}
> ***
> %% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
> qtp1424237190-118, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> %% Invalidated:  [Session-1, SSL_NULL_WITH_NULL_NULL]
> qtp1424237190-118, SEND TLSv1 ALERT:  fatal, description = handshake_failure
> qtp1424237190-118, WRITE: TLSv1 Alert, length = 2
> qtp1424237190-118, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common
> {code}
> The root cause is that if we want to add a Jetty hander, we need to stop Jetty server. As part of Jetty server stop process, it's SslConnectionFactory also needs to stop, as well as SslContextFactory. Here is doStop() method of SslContextFactory in Jetty 9.2.x code base:
> {code}
> public class SslContextFactory extends AbstractLifeCycle
> ...
>     protected void doStop() throws Exception
>      {
>          _context = null;
>          super.doStop();
>      }
> {code}
> We can see that it resets SSLContext to null. When the jetty server restarts, SslConnectionFactory creates a new SSLContext object instead, therefore, losing all the SSL properties from the original <camel:sslContextParameters> configuration. 
> So we need to preserve the SSLContext before stopping the jetty server and reset the SSLContext back and then restart it.



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