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" <seiz...@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: williamstev...@gmail.com [williamstev...@gmail.com] on behalf of >Will Stevens [wstev...@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.y...@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" <wstev...@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 >> >>
