You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Gerald Kallas <ca...@mailbox.org> on 2020/02/09 22:48:59 UTC
camel-jetty HTTPS consumer still fails with handshake failure -
possible bug?
Hi everybody,
after several research I did create the following Blueprint DSL route that still fails with a TLS handshake failure.
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<sslContextParameters id="sslContextParameters" xmlns="http://camel.apache.org/schema/blueprint">
<secureSocketProtocolsFilter>
<include>TLSv1.2</include>
<include>TLSv1.1</include>
</secureSocketProtocolsFilter>
<cipherSuitesFilter>
<include>.*</include>
<exclude></exclude>
</cipherSuitesFilter>
<keyManagers keyPassword="xxxxx">
<keyStore resource="etc/truststore.jks" password="xxxxx"/>
</keyManagers>
<trustManagers>
<keyStore resource="etc/casag.p12" password="xxxxx"/>
</trustManagers>
</sslContextParameters>
<camelContext id="WEBISP001" xmlns="http://camel.apache.org/schema/blueprint">
<route id="WEBISP001">
<from uri="jetty:https://0.0.0.0:8444/hello?sslContextParameters=sslContextParameters" />
<log message="hello request body: ${in.body}" />
</route>
</camelContext>
</blueprint>
The request to the endpoint still fails with
curl -vvv --insecure --location --request POST 'https://host:8444/hello' --data-raw 'Hello World!'
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 10.0.0.147...
* TCP_NODELAY set
* Connected to host (10.0.0.147) port 8444 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
The log while deployment shows that the sslContextParameters shows that the SSL context parameters are being applied.
It seems to me like a bug or do I still miss something?
Any help is highly appreciated.
Best
- Gerald
Re: camel-jetty HTTPS consumer still fails with handshake failure -
possible bug?
Posted by Gerald Kallas <ca...@mailbox.org>.
Finally I did the configuration working with some help of Jiri Ondrusek (many thanks!).
First file/bundle ..
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
<sslContextParameters id="sslContextParameters" xmlns="http://camel.apache.org/schema/blueprint">
<keyManagers keyPassword="xxxxx">
<keyStore resource="etc/keystore.p12" password="xxxxx"/>
</keyManagers>
</sslContextParameters>
<service ref="sslContextParameters" auto-export="all-classes" />
</blueprint>
The first one could be referred in any other blueprint file/bundle.
Second file/bundle ..
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">
<reference id="sslContextParameters" interface="org.apache.camel.support.jsse.SSLContextParameters" ext:proxy-method="classes"/>
<camelContext id="WEBISP001" xmlns="http://camel.apache.org/schema/blueprint">
<route id="WEBISP001">
<from uri="jetty:https://0.0.0.0:8444/hello?sslContextParameters=#sslContextParameters" />
<log message="hello request body: ${in.body}" />
</route>
</camelContext>
</blueprint>
Many thanks again for all the help.
Best
- Gerald
> Gerald Kallas <ca...@mailbox.org> hat am 9. Februar 2020 23:48 geschrieben:
>
>
> Hi everybody,
>
> after several research I did create the following Blueprint DSL route that still fails with a TLS handshake failure.
>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
>
> <sslContextParameters id="sslContextParameters" xmlns="http://camel.apache.org/schema/blueprint">
> <secureSocketProtocolsFilter>
> <include>TLSv1.2</include>
> <include>TLSv1.1</include>
> </secureSocketProtocolsFilter>
> <cipherSuitesFilter>
> <include>.*</include>
> <exclude></exclude>
> </cipherSuitesFilter>
> <keyManagers keyPassword="xxxxx">
> <keyStore resource="etc/truststore.jks" password="xxxxx"/>
> </keyManagers>
> <trustManagers>
> <keyStore resource="etc/casag.p12" password="xxxxx"/>
> </trustManagers>
> </sslContextParameters>
>
> <camelContext id="WEBISP001" xmlns="http://camel.apache.org/schema/blueprint">
>
> <route id="WEBISP001">
> <from uri="jetty:https://0.0.0.0:8444/hello?sslContextParameters=sslContextParameters" />
> <log message="hello request body: ${in.body}" />
> </route>
>
> </camelContext>
>
> </blueprint>
>
> The request to the endpoint still fails with
>
> curl -vvv --insecure --location --request POST 'https://host:8444/hello' --data-raw 'Hello World!'
> Note: Unnecessary use of -X or --request, POST is already inferred.
> * Trying 10.0.0.147...
> * TCP_NODELAY set
> * Connected to host (10.0.0.147) port 8444 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> CApath: none
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.3 (IN), TLS alert, handshake failure (552):
> * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
> * Closing connection 0
> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
>
> The log while deployment shows that the sslContextParameters shows that the SSL context parameters are being applied.
>
> It seems to me like a bug or do I still miss something?
>
> Any help is highly appreciated.
>
> Best
> - Gerald