cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: Handling Self Signed Certs
Date Thu, 06 Jun 2013 22:40:03 GMT
Will,

We don't have a common HTTPS client yet, as far as I know, different
module developers probably are using slight different way to deal with
self-signed certificate, it is a good time to consolidate it now if it is
not too late. You may make the facility available in cloud-utils package
and encourage adoption from these modules.

Some modules, i.e., download manager, API module to hypervisor hosts have
the similar situation.


Kelven

On 6/6/13 2:33 PM, "Soheil Eizadi" <seizadi@infoblox.com> wrote:

>What is missing is a facility to import a certificate into the store. If
>it was available you could use it for self signed CERTS. Ideally it
>should be part of GUI to add devices.
>
>I am implementing a similar HTTP Client. You are using DefaultHttpClient
>so it is based on the newer Apache libraries. The ones I found in
>CloudStack were older Commons HttpClient which was EOL.
>
>In my case I planned to wrap the Client as you have for development and
>for production have an API to import a certificate for SSL into the
>Certificate Store.
>
>I would call to AuthScope(host, 443) to limit access to only the specific
>host and port.
>
>-Soheil
>________________________________________
>From: williamstevens@gmail.com [williamstevens@gmail.com] on behalf of
>Will Stevens [wstevens@cloudops.com]
>Sent: Thursday, June 06, 2013 1:08 PM
>To: dev@cloudstack.apache.org
>Subject: Re: Handling Self Signed Certs
>
>Hey Kelven,
>I am using the same https client libraries as elsewhere in Cloudstack
>(well
>one of them because there is more than one version of http client libs
>currently available in CS).
>
>I am using this client:
>import org.apache.http.impl.client.DefaultHttpClient;
>
>I initialize it like this:
>_httpclient = new DefaultHttpClient();
>
>Then if self signed certs are allowed, I currently have a utility library
>in my plugin which allows me to do this:
>// Allows you to connect via SSL using unverified certs
>_httpclient = HttpClientWrapper.wrapClient(_httpclient);
>
>Is there a class that already exists in CloudStack which I can use to wrap
>my client to enable unverified certs, or will I need to add one?  Should I
>create a global setting such as 'Allow unverified SSL certs' which would
>be
>checked by the code to determine if the http client should be wrapped?
>
>Thx, Will
>
>
>On Thu, Jun 6, 2013 at 2:43 PM, Kelven Yang <kelven.yang@citrix.com>
>wrote:
>
>> Will,
>>
>> We have several other integrated components that have the similar
>> situation, it makes sense to consolidate the HTTPS client we used across
>> CloudStack and have a global configuration to deal with self-signed
>> certificate for all in testing or POC.
>>
>> To help testing/POC process to be smooth, we may allow self-signed
>> certificate by default(which is the current behave), security sensitive
>> customers should disallow self-signed certificates in their production
>> environment.
>>
>> Kelven
>>
>> On 6/6/13 9:08 AM, "Will Stevens" <wstevens@cloudops.com> wrote:
>>
>> >Hey All,
>> >I am building integration between CS and an external Palo Alto Firewall
>> >device.  The API calls to the PA device are done over HTTPS.  In some
>> >cases
>> >(like testing or a POC), it makes sense to use a self signed cert for
>>this
>> >connection.
>> >
>> >Currently I have a little http client wrapper which allows the use of a
>> >self signed cert.  Obviously, I do not want to use the wrapper when a
>>real
>> >cert is used.
>> >
>> >What I am thinking of doing is adding a checkbox on the 'Add Palo Alto
>> >Device' configuration overlay with an option for 'Using a self signed
>> >cert'.  If this checkbox is checked, then the http client wrapper is
>>used
>> >so the self signed cert will not throw errors, if it is not checked,
>>the
>> >the http client wrapper will not be used and errors will be thrown if
>>the
>> >cert is not valid.
>> >
>> >Is this a realistic approach to this problem?  Is this problem handled
>>in
>> >other parts of the system in a different way?
>> >
>> >Thanks,
>> >
>> >Will
>>
>>


Mime
View raw message