Re: https4 component failing to send client SSL certificate

[ski n <ra...@gmail.com>]

Hi Scott,

Code looks fine. Did you check if the certificate is correctly in the
truststore (keystore isn't really needed in this use case). You can use
Keystore explorer to check the certificates:

https://keystore-explorer.org/downloads.html

You may also check if it works with Assimbly (as it uses same Camel code):

Download:https://github.com/assimbly/gateway/releases
Documentation: https://github.com/assimbly/gateway/wiki/user-guide +
https://github.com/assimbly/gateway/wiki/TLS-Certificates

Raymond



Op wo 1 mei 2019 om 22:23 schreef Scott Cornell <cornells@trinity-health.org
>:

> I am attempting to enable 2 way SSL certificate authentication on a route
> using an https4 component in a Camel 2.15.1 running in a Karaf 2.4
> container (actually, if it matters, the camel and karaf instances are
> running as part of a JBoss Fuse fabric ensemble - so really I'm running
> Camel 2.15.1.redhat-621090 and Karaf 2.4.0.redhat-621090).  Anyway, per the
> online http4 component docs and this
> https://gist.github.com/kameshsampath/d6a55cafe4ab23593ccfd8e5e2451bcf
> helpful github example, I *think* I have the correct code to create an
> endpoint that will send the client certificate as follows:
>
>                 KeyStoreParameters keyStoreParameters = new
> KeyStoreParameters();
>                 keyStoreParameters.setResource(clientKeyStorePath);
>                 keyStoreParameters.setPassword (clientKeyStorePassword);
>
>                 KeyManagersParameters keyManagersParameters = new
> KeyManagersParameters();
>                 keyManagersParameters.setKeyStore(keyStoreParameters);
>                 keyManagersParameters.setKeyPassword(clientKeyPassword);
>
>                 KeyStoreParameters trustStoreParameters = new
> KeyStoreParameters();
>                 trustStoreParameters.setResource(serverKeyStorePath);
>                 trustStoreParameters.setPassword(serverKeyStorePassword);
>                 TrustManagersParameters trustManagersParameters = new
> TrustManagersParameters();
>                 trustManagersParameters.setKeyStore(trustStoreParameters);
>
>                 SSLContextParameters sslContextParameters = new
> SSLContextParameters();
>                 sslContextParameters.setKeyManagers(keyManagersParameters);
>
> sslContextParameters.setTrustManagers(trustManagersParameters);
>
>                 HttpComponent httpComponent =
> getContext().getComponent("https4", HttpComponent.class);
>
> httpComponent.setSslContextParameters(sslContextParameters);
>
>                 Endpoint httpComponent =
> httpComponent.createEndpoint("https4://the.target.server");
>
> There is no error stack trace, the component calls the target server
> properly, and it even accepts and trusts the server's SSL cert.  So I know
> both certificate stores are being loaded and at least the trustManager
> piece of the code works which would seem to indicate to me that the correct
> sslContext is being used.  However, the server responds with a 401 Not
> Authorized status with a message body indicating the client certificate is
> missing.  Sure enough, enabling javax.net.ssl debugging on the JVM, I see
> this sequence in the SSL handshake
>
> <snip>
> 0160: D7 14 CA 11 50 39 4D 49   BE AD 6D DD 1C           ....P9MI..m..
> *** ServerHelloDone
> [read] MD5 and SHA1 hashes:  len = 4
> 0000: 0E 00 00 00                                        ....
> *** ECDHClientKeyExchange
> ECDH Public value:  {...
> [write] MD5 and SHA1 hashes:  len = 102
> <snip>
>
> If I'm understanding the entire SSL handshake process correctly, there's
> supposed to be a Certificate message written by the client to the server
> immediately after the SeverHelloDone message and prior to the while key
> exchange handshaking.  But I don't see it, nor do I see it anywhere else in
> the SSL debug dump.  Can anyone suggest what I might be doing wrong here?
>
> Confidentiality Notice:
> This e-mail, including any attachments is the property of Trinity Health
> and is intended for the sole use of the intended recipient(s). It may
> contain information that is privileged and confidential.  Any unauthorized
> review, use, disclosure, or distribution is prohibited. If you are not the
> intended recipient, please delete this message, and reply to the sender
> regarding the error in a separate email.
>
>