You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Will Stevens <ws...@cloudops.com> on 2013/06/06 18:08:47 UTC
Handling Self Signed Certs
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
Re: Handling Self Signed Certs
Posted by Mike Tutkowski <mi...@solidfire.com>.
Oh, OK, Will, no problem. I wasn't sure if it would make it into 4.2, so I
figured I'd check in with you on that.
Thanks!
On Tue, Jun 11, 2013 at 10:40 AM, Kelven Yang <ke...@citrix.com>wrote:
> Will,
>
> Security is one of the important aspects in any system(if not of topmost),
> it is a good move to consolidate it. Thanks for your effort!
>
> Kelven
>
> On 6/11/13 9:27 AM, "Will Stevens" <ws...@cloudops.com> wrote:
>
> >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.tutkowski@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.yang@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" <ws...@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 <ke...@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" <se...@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
> >><ke...@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" <ws...@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.tutkowski@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the
> >> cloud<http://solidfire.com/solution/overview/?video=play>
> >> * *
> >>
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Handling Self Signed Certs
Posted by Kelven Yang <ke...@citrix.com>.
Will,
Security is one of the important aspects in any system(if not of topmost),
it is a good move to consolidate it. Thanks for your effort!
Kelven
On 6/11/13 9:27 AM, "Will Stevens" <ws...@cloudops.com> wrote:
>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.tutkowski@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.yang@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" <ws...@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 <ke...@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" <se...@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
>><ke...@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" <ws...@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.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> **
>>
Re: Handling Self Signed Certs
Posted by Will Stevens <ws...@cloudops.com>.
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.tutkowski@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.yang@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" <ws...@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 <ke...@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" <se...@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 <ke...@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" <ws...@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>
Re: Handling Self Signed Certs
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <ke...@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" <ws...@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 <ke...@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" <se...@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 <ke...@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" <ws...@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Handling Self Signed Certs
Posted by Kelven Yang <ke...@citrix.com>.
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" <ws...@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 <ke...@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" <se...@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 <ke...@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" <ws...@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
>> >>
>> >>
>>
>>
Re: Handling Self Signed Certs
Posted by Chiradeep Vittal <Ch...@citrix.com>.
+1 to per-device
On 6/10/13 9:04 AM, "Will Stevens" <ws...@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 <ke...@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" <se...@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 <ke...@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" <ws...@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
>> >>
>> >>
>>
>>
Re: Handling Self Signed Certs
Posted by Will Stevens <ws...@cloudops.com>.
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 <ke...@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" <se...@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 <ke...@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" <ws...@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
> >>
> >>
>
>
Re: Handling Self Signed Certs
Posted by Kelven Yang <ke...@citrix.com>.
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" <se...@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 <ke...@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" <ws...@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
>>
>>
RE: Handling Self Signed Certs
Posted by Soheil Eizadi <se...@infoblox.com>.
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 <ke...@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" <ws...@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
>
>
Re: Handling Self Signed Certs
Posted by Will Stevens <ws...@cloudops.com>.
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 <ke...@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" <ws...@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
>
>
Re: Handling Self Signed Certs
Posted by Kelven Yang <ke...@citrix.com>.
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" <ws...@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