jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adrian.f.c...@gmail.com>
Subject Re: Self-signed certs
Date Fri, 03 Oct 2014 03:10:59 GMT
This sounds like an http transport concern, Yury.

Perhaps you can try a different driver, such as our okhttp one? Not saying
this will automatically solve, but I am pretty sure the answer will be in
the http driver. We may have a singleton somewhere in the default driver
(which we could look into).

Let us know!
-A
On Oct 2, 2014 3:12 PM, "Yury Kats" <yurykats@yahoo.com> wrote:

> I'm using jclouds 1.8 to communicate with Openstack Keystone server.
> The server is using a self-signed cert. My client detects SSL connection
> failure and allows the user to install the cert, which I add to JVM's trust
> store.
>
> At this point I expect jclouds connections to succeed, but they continue
> to fail. Until I shutdown the client and restart.
> If the JVM trust store is loaded with the cert before jclouds makes its
> first connection, all is good.
> But if I change (add/remove) certs after the 1st connection is made, then
> the change in JVM's trust store does not take effect on jclouds.
> (For reference, I'm using AWS SDK in the same client, and there the change
> takes effect immediately).
>
> Does jclouds cache connections or contexts? Is there a way to make it
> "fully reconnect" (for a lack of a better term)?
>
> My code to talk to Keystone is like this:
>         KeystoneApi keystoneAPI = ContextBuilder.newBuilder(new
> KeystoneApiMetadata())
>                 .endpoint(url)
>                 .credentials(tenant + ":" + user, key)
>                 .buildApi(KeystoneApi.class);
>
>         keystoneAPI.getServiceApi().listTenants();
>
> PS: I am aware of Constants.PROPERTY_TRUST_ALL_CERTS, but that's not what
> I want.
>
> Thanks,
> Yury
>

Mime
View raw message