Thanks for the last code segment - pass the SslConfigurator instance not the SSLContext otherwise it should not work.
Michal
> On 3 Feb, 2015, at 16:49 , John MacAuley <john_at_blackacorn.ca> wrote:
>
> Michal,
>
> I should have expanded the last code segment. Here is what it looked like:
>
> SslConfigurator sslConfig = SslConfigurator.newInstance()
> .trustStoreFile(trustStore)
> .trustStorePassword(trustStorePassword)
> .trustStoreType("JKS")
> .trustManagerFactoryAlgorithm("PKIX")
>
> .keyStoreFile(keyStore)
> .keyPassword(keyStorePassword)
> .keyStoreType("JKS")
> .keyManagerFactoryAlgorithm("SunX509")
> .keyStoreProvider("SUN")
>
> .securityProtocol("SSL");
>
> clientConfig.property(ApacheClientProperties.SSL_CONFIG, sslConfig.createSSLContext());
>
> I think I did what you are proposing but will retry just to make sure.
>
> Thanks,
> John
>
> On 2015-02-03, at 10:43 AM, Michal Gajdos <michal.gajdos_at_oracle.com> wrote:
>
>> Hi John,
>>
>> there is a bug in our Apache HttpClient connector. It doesn’t take SSLContext from the client but it expects a certain property to be set. Specifically it’s ApacheClientProperties.SSL_CONFIG (see [1]). Until this bug gets fixed, you need to use:
>>
>> SslConfigurator sslConfig = …;
>> ClientBuilder.newBuilder().property(ApacheClientProperties.SSL_CONFIG, sslConfig).build();
>>
>> [1] https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/apache/connector/ApacheClientProperties.html#SSL_CONFIG
>>
>> Michal
>>
>>> On 3 Feb, 2015, at 16:13 , John MacAuley <john_at_blackacorn.ca> wrote:
>>>
>>> Peoples,
>>>
>>> I have been using Jersey with the default HttpUrlConnectorProvider but decided to switch to the ApacheConnectorProvider for chunked POST support and 100-Continue for better SSL re-negotiation support on the POST. With the HttpUrlConnectorProvider I was able to fully configure SSL for my needs using the standard javax.net.ssl.*Store properties. I configured my own key and trust stores. I have configured SSL on httpd for client authentication (SSLVerifyClient).
>>>
>>> On startup with the HttpUrlConnectorProvider and SSL debug enabled I see the keyStore and trustStore initialization occur with my private key and a list of trusted certificates. When the POST goes out I see the initial SSL session being set up, and when httpd determines the POST is to a "SSLVerifyClient" protected URL it initiates a re-negotition. I then see the re-negotition start, the CertificateRequest with the list of certificate authorities followed up with ServerHelloDone. I then see the my matching private key being selected (matching alias), the Certificate chain for my key being dumped, then a run to completion on SSL setup (TLSv1).
>>>
>>> When I switched to the ApacheConnectorProvider I see my truststore getting loaded but not the keystore. The client authentication fails since it cannot find a matching private key.
>>>
>>> *** ServerHelloDone
>>> [read] MD5 and SHA1 hashes: len = 4
>>> 0000: 0E 00 00 00 ....
>>> *** Certificate chain
>>> ***
>>> *** ECDHClientKeyExchange
>>>
>>> I then used the following to initialize the default SSL context for the client:
>>>
>>> SSLContext sslContext = SSLContexts.createSystemDefault();
>>> client = ClientBuilder.newBuilder().sslContext(sslContext).withConfig(clientConfig).build();
>>>
>>> I see the truststore and keystore being loaded such as below, but get the same result.
>>>
>>> SslConfigurator sslConfig = SslConfigurator.newInstance()
>>> .trustStoreFile(trustStore)
>>> .trustStorePassword(trustStorePassword)
>>> .trustStoreType("JKS")
>>> .trustManagerFactoryAlgorithm("PKIX")
>>>
>>> .keyStoreFile(keyStore)
>>> .keyPassword(keyStorePassword)
>>> .keyStoreType("JKS")
>>> .keyManagerFactoryAlgorithm("SunX509")
>>> .keyStoreProvider("SUN")
>>>
>>> .securityProtocol("SSL");
>>>
>>> I tried other ways to initialize the truststore and keystore with the same results.
>>>
>>> Anyone have a clue why this is not working?
>>>
>>> Thanks!
>>> John
>>
>