When I went looking in CS for the HTTP clients that were already available, I found the one that Soheil is using as well as the new apache one. I am using the new apache one because I was assuming it was going to be the preferred one going forward.
I will clean up my wrapper and make it available in the cloud-utils package. The only question now is if the 'allow unverified certs' should be a global setting or a per device setting. I tend to think that it should be per device because that isolates the functionality a little better. However, by creating a global setting it makes the concept more accessible to other developers and centralizes the setting for the user so they only have to specify the setting in one place and all devices which have been written to conform to that setting will allow unverified certs. I think there are pros and cons to both approaches. I am fine to implement my code either way, so more feedback on this choice would be appreciated. ws On Thu, Jun 6, 2013 at 6:40 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > 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 > >> > >> > >
