+1 to per-device On 6/10/13 9:04 AM, "Will Stevens" <wstev...@cloudops.com> wrote:
>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 >> >> >> >> >> >>
