Kelven, I like the idea of having a global setting that can be overridden by the developers at the device level if they want to offer finer control. I think this gives us the best of both worlds.
Mike, I am not sure I will be able to get it into 4.2 unless I release it as its own patch prior to my code for the Palo Alto integration getting in. If we iron out how we expect the functionality to behave, I can push to get it in earlier than the rest of my code. Will On Tue, Jun 11, 2013 at 12:22 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > I would be quite interesting in seeing where we go with this. Are we > talking about doing this in 4.2? > > I have a customer playing around with the storage plug-in I've been > developing and we are having a little trouble in their environment with > certificates. If we had just one way of handling them, it would be great > (could just hand over the documentation for how this kind of thing works in > general in CloudStack). > > > On Mon, Jun 10, 2013 at 11:07 AM, Kelven Yang <kelven.y...@citrix.com > >wrote: > > > Will, > > > > Thanks for the effort in getting a common wrapper into utils package. > > > > As for the policy decision(whether or not to make a global flag or a > > per-device option), both have pros and cons, we can wait and see the > > feedbacks from others in the community. > > > > Considering the legacy installations and the fact that we allow > > self-signed certificates by default in existing releases, I personally > > think that having a global flag is a much economic way to get this > feature > > in without too much disruptions. Of course, to have fine-control of it, > we > > can always allow per-device overridden policy as well. > > > > Kelven > > > > > > 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 > > >> >> > > >> >> > > >> > > >> > > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* >
