Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Xav Paice]

Setting an env var seems like a very straightforward way to do this, and
means the deployer can easily control the specifics of what they want
without any code changes - that suits me perfectly.  Adding some
documentation somewhere to that effect might be handy but this is indeed a
bit of an edge case if the distro packages already patch requests to
override the default anyway.  I only tripped over this when I started using
virtual environments and pip, and wasn't expecting the distro package to
alter the behaviour of the library it ships.

Thanks for the feedback and discussion, it's been really helpful.

On 17 November 2015 at 23:30, Cory Benfield  wrote:

>
> > On 16 Nov 2015, at 11:54, Sean Dague  wrote:
> > That sounds pretty reasonable to me. I definitely support the idea that
> > we should be using system CA by default, even if that means overriding
> > requests in our tools.
>
> Setting REQUESTS_CA_BUNDLE is absolutely the way to go about this. In
> requests 2.9.0 we will also support the case that REQUESTS_CA_BUNDLE points
> to a directory of certificates, not a single certificate file, so this
> should cover all Linux distributions methods of distributing
> OpenSSL-compatible certificates.
>
> If OpenStack wants to support using Windows and OS X built-in certificate
> stores, that's harder. This is because both systems do not use PEM-file
> based certificate distribution, which means OpenSSL can’t read them.
>
> Cory
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Cory Benfield]

> On 16 Nov 2015, at 11:54, Sean Dague  wrote:
> That sounds pretty reasonable to me. I definitely support the idea that
> we should be using system CA by default, even if that means overriding
> requests in our tools.

Setting REQUESTS_CA_BUNDLE is absolutely the way to go about this. In requests 
2.9.0 we will also support the case that REQUESTS_CA_BUNDLE points to a 
directory of certificates, not a single certificate file, so this should cover 
all Linux distributions methods of distributing OpenSSL-compatible certificates.

If OpenStack wants to support using Windows and OS X built-in certificate 
stores, that's harder. This is because both systems do not use PEM-file based 
certificate distribution, which means OpenSSL can’t read them.

Cory


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Sean Dague]

On 11/16/2015 01:03 AM, Jamie Lennox wrote:
> 
> 
> On 14 November 2015 at 19:09, Xav Paice  > wrote:
> 
> Hi,
> 
> I'm sure I'm not the only one that likes to use SSL everywhere
> possible, and doesn't like to pay for 'real' ssl certs for dev
> environments.  Figuring out how to get requests to allow connection
> to the self signed cert would have paid for a real cert many times over.
> 
> When I use an SSL cert with a CA not in the Mozilla bundle, and use
> keystonemiddleware to access Keystone endpoints, the ssl
> verification rightly fails.  It turns out requests doesn't use the
> system ca cert bundle, but has it's own.  It's also got a nice easy
> config option to set which ca cert bundle you want to use -
> 
> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
> 
> How do people feel about having that as a config option set
> somewhere, so we can specify a ca cert in, say, heat.conf, so that
> we can continue with the self signed certs of cheapness without
> needing to hack up the cacert.pem that comes with requests, or find
> a way to pass in environment variables?
> 
> Am I barking up the wrong tree here?  How would I go about writing a
> blueprint for this, and for which project?  I guess it's something
> that would need to be added to all the projects in the
> keystone_authtoken section?  Or is there a central place where
> common configs like this can live?
> 
>  
> So this is an area that requests upstream and distros have fought about
> for a while now, that and bundling. Typically the distros patch the
> requests package so that it correctly reflects the system environment,
> so if you yum install or apt-get install python-requests then it will
> work with the system CAs. If you are running from a virtualenv/pip
> installed python-requests it wont.
> 
> Ideally we are moving everything to using keystoneclient/keystoneauth
> sessions. These have support for cafile from the built in options
> loader, so in future there should be config options that will allow you
> to always specify a CA file to use if you're willing to chase down all
> the config values.
> 
> For now the easiest way i know to do this is using the
> REQUESTS_CA_BUNDLE environment variable. If found (and nothing else
> specified) this will be used as the default CA bundle file instead of
> the inbuilt one. It also respects the CURL_CA_BUNDLE variable.
> 
> I'm not sure if people would mind if we did some OS discovery and just
> overrode the requests defaults to always find the system CA. It doesn't
> bother me. But we could really easily add our own OS_CA_BUNDLE env
> variable to do the same things as requests and override a system location.

That sounds pretty reasonable to me. I definitely support the idea that
we should be using system CA by default, even if that means overriding
requests in our tools.

I definitely don't want to be adding a ton of server params to set this.
Servers talking to other servers through clients should use the system
CA for sure.

That will have a knock on effect about using it for python clients
directly, but that seems like the right option.

What's the expected way that a user would add a cert for a self signed
cloud to their laptop? It seems like if the answer involves config
outside of certutil (on a linux environment) then it's probably on the
wrong track.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Jamie Lennox]

On 14 November 2015 at 19:09, Xav Paice  wrote:

> Hi,
>
> I'm sure I'm not the only one that likes to use SSL everywhere possible,
> and doesn't like to pay for 'real' ssl certs for dev environments.
> Figuring out how to get requests to allow connection to the self signed
> cert would have paid for a real cert many times over.
>
> When I use an SSL cert with a CA not in the Mozilla bundle, and use
> keystonemiddleware to access Keystone endpoints, the ssl verification
> rightly fails.  It turns out requests doesn't use the system ca cert
> bundle, but has it's own.  It's also got a nice easy config option to set
> which ca cert bundle you want to use -
> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
>
> How do people feel about having that as a config option set somewhere, so
> we can specify a ca cert in, say, heat.conf, so that we can continue with
> the self signed certs of cheapness without needing to hack up the
> cacert.pem that comes with requests, or find a way to pass in environment
> variables?
>
> Am I barking up the wrong tree here?  How would I go about writing a
> blueprint for this, and for which project?  I guess it's something that
> would need to be added to all the projects in the keystone_authtoken
> section?  Or is there a central place where common configs like this can
> live?
>

So this is an area that requests upstream and distros have fought about for
a while now, that and bundling. Typically the distros patch the requests
package so that it correctly reflects the system environment, so if you yum
install or apt-get install python-requests then it will work with the
system CAs. If you are running from a virtualenv/pip installed
python-requests it wont.

Ideally we are moving everything to using keystoneclient/keystoneauth
sessions. These have support for cafile from the built in options loader,
so in future there should be config options that will allow you to always
specify a CA file to use if you're willing to chase down all the config
values.

For now the easiest way i know to do this is using the REQUESTS_CA_BUNDLE
environment variable. If found (and nothing else specified) this will be
used as the default CA bundle file instead of the inbuilt one. It also
respects the CURL_CA_BUNDLE variable.

I'm not sure if people would mind if we did some OS discovery and just
overrode the requests defaults to always find the system CA. It doesn't
bother me. But we could really easily add our own OS_CA_BUNDLE env variable
to do the same things as requests and override a system location.



>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Monty Taylor]

On 11/15/2015 03:13 PM, Clint Byrum wrote:

Excerpts from Xav Paice's message of 2015-11-15 11:45:55 -0800:

After having a brief discussion this morning (NZ time) on the
#python-requests irc, it seems that using the system CA bundle is a "Not a
chance" situation.  They've tried, and found it unmaintainable due to the
vast variations between system layouts (multiple OS, not just multiple
distro).  I can see their point.



Somehow we got all the distros and unices to agree where timezone, hosts,
etc. go.  Perhaps it's time we form a group to get a single place. I
commend the requests authors for trying, and think this is something
that must affect other languages as well.


Others have mentioned env vars not working particularly well either - which
really leaves a config option and that is something that ops/deployers can
tailor to suit their particular system without either the requests people
nor the OpenStack people having to maintain.



Config option is fine. But I wonder if we could also just write a
wrapper that understands the distros we support, and picks the system
level one. There are, what, 2 schemes to support? 3?


We already wrap requests.Session in keystoneauth.

We already have options to keystoneauth1.session.Session to tell it 
where the cacert, cert and key are.


Both of those are done and are everywhere. SO - potential tasks:

1) add ability to specify cert/cacert/key parameters in config files for 
places where we're configuring one service's connections to another service


2) maybe work the default behavior of keystoneauth1.session.Session to 
detect which OS it's on and set the default values such that system CA 
bundles are used.


Of course, this is all predicated on getting everything on keystoneauth 
- but that's a current TODO-list item anyway.


Once we do that, 1 actually becomes easier - because keystoneauth 
already has: keystoneauth1.loading.register_session_conf_options(), 
which adds all the appropriate Session conf parameters to a given 
oslo.config CONF object.


Monty

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Clint Byrum]

Excerpts from Xav Paice's message of 2015-11-15 11:45:55 -0800:
> After having a brief discussion this morning (NZ time) on the
> #python-requests irc, it seems that using the system CA bundle is a "Not a
> chance" situation.  They've tried, and found it unmaintainable due to the
> vast variations between system layouts (multiple OS, not just multiple
> distro).  I can see their point.
> 

Somehow we got all the distros and unices to agree where timezone, hosts,
etc. go.  Perhaps it's time we form a group to get a single place. I
commend the requests authors for trying, and think this is something
that must affect other languages as well.

> Others have mentioned env vars not working particularly well either - which
> really leaves a config option and that is something that ops/deployers can
> tailor to suit their particular system without either the requests people
> nor the OpenStack people having to maintain.
> 

Config option is fine. But I wonder if we could also just write a
wrapper that understands the distros we support, and picks the system
level one. There are, what, 2 schemes to support? 3?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Xav Paice]

After having a brief discussion this morning (NZ time) on the
#python-requests irc, it seems that using the system CA bundle is a "Not a
chance" situation.  They've tried, and found it unmaintainable due to the
vast variations between system layouts (multiple OS, not just multiple
distro).  I can see their point.

Others have mentioned env vars not working particularly well either - which
really leaves a config option and that is something that ops/deployers can
tailor to suit their particular system without either the requests people
nor the OpenStack people having to maintain.

On 16 November 2015 at 04:26, Adam Young  wrote:

> On 11/14/2015 03:09 AM, Xav Paice wrote:
>
> Hi,
>
> I'm sure I'm not the only one that likes to use SSL everywhere possible,
> and doesn't like to pay for 'real' ssl certs for dev environments.
> Figuring out how to get requests to allow connection to the self signed
> cert would have paid for a real cert many times over.
>
> When I use an SSL cert with a CA not in the Mozilla bundle, and use
> keystonemiddleware to access Keystone endpoints, the ssl verification
> rightly fails.  It turns out requests doesn't use the system ca cert
> bundle, but has it's own.  It's also got a nice easy config option to set
> which ca cert bundle you want to use -
> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
>
> How do people feel about having that as a config option set somewhere, so
> we can specify a ca cert in, say, heat.conf, so that we can continue with
> the self signed certs of cheapness without needing to hack up the
> cacert.pem that comes with requests, or find a way to pass in environment
> variables?
>
> Am I barking up the wrong tree here?  How would I go about writing a
> blueprint for this, and for which project?  I guess it's something that
> would need to be added to all the projects in the keystone_authtoken
> section?  Or is there a central place where common configs like this can
> live?
>
>
>
> I would say that the right approach is to add the CA to the system bundle
> for the calling machine.  Requests not using the System defaults is a Bug.
>
> I suspect that the reason that they do this is the unwillingness of the
> Requests developers to have to battle NSS: The Dogtag developers have a
> write up including the steps necessary to get NSS support into Requests.
> http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API
>
>
> On a Fedora system, the python-requests RPM depends on ca-certificates,
> which is updated more frequently than that document indicates;
>
> rpm --query  --list ca-certificates
>
> Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as
> well as /etc/ssl and /usr/share/pki
>
>
> I suspect that Debian based systems do something comparable, although I
> don't have on handy to chack.
>
>
> So, short answer: use the system tools to update.  Lets not make an end
> run around system security.  A config value is another path to Audit.
>
>
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Xav Paice]

Yeah, using the system CAs would be my preference but I do understand that
in some cases, things in a virtual environment should stay in that virtual
environment.  Maybe the requests developers would prefer to see the whole
thing isolated, but it does make things rather difficult when requests is a
part of something much larger and more complex.  See
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-11-12.log.html#t2015-11-12T18:20:05
as well, some good discussion going on.

cc'ing Clark specifically since he was so helpful in getting this thing
sorted.


So the consensus here is to discuss using the system CAs with the requests
devs rather than add a config item to OpenStack?

On 16 November 2015 at 05:14, Monty Taylor  wrote:

> On 11/15/2015 10:26 AM, Adam Young wrote:
>
>> On 11/14/2015 03:09 AM, Xav Paice wrote:
>>
>>> Hi,
>>>
>>> I'm sure I'm not the only one that likes to use SSL everywhere
>>> possible, and doesn't like to pay for 'real' ssl certs for dev
>>> environments.  Figuring out how to get requests to allow connection to
>>> the self signed cert would have paid for a real cert many times over.
>>>
>>> When I use an SSL cert with a CA not in the Mozilla bundle, and use
>>> keystonemiddleware to access Keystone endpoints, the ssl verification
>>> rightly fails.  It turns out requests doesn't use the system ca cert
>>> bundle, but has it's own.  It's also got a nice easy config option to
>>> set which ca cert bundle you want to use -
>>>
>>> http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification
>>>
>>> How do people feel about having that as a config option set somewhere,
>>> so we can specify a ca cert in, say, heat.conf, so that we can
>>> continue with the self signed certs of cheapness without needing to
>>> hack up the cacert.pem that comes with requests, or find a way to pass
>>> in environment variables?
>>>
>>> Am I barking up the wrong tree here?  How would I go about writing a
>>> blueprint for this, and for which project?  I guess it's something
>>> that would need to be added to all the projects in the
>>> keystone_authtoken section?  Or is there a central place where common
>>> configs like this can live?
>>>
>>
>>
>> I would say that the right approach is to add the CA to the system
>> bundle for the calling machine.  Requests not using the System defaults
>> is a Bug.
>>
>
>
> Installing CAs into the system is easy, but it might take a little while
> to find the magic incantation:
>
> On Debian derived systems:
>
> - Copy the cert to /usr/local/share/ca-certificates
> - Execute /usr/sbin/update-ca-certificates
>
> On RedHat derived systems:
>
> - Copy the cert to /etc/pki/ca-trust/source/anchors
> - Execute /usr/bin/update-ca-trust extract
>
>
>
> I suspect that the reason that they do this is the unwillingness of the
>> Requests developers to have to battle NSS: The Dogtag developers have a
>> write up including the steps necessary to get NSS support into Requests.
>> http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API
>>
>>
>> On a Fedora system, the python-requests RPM depends on ca-certificates,
>> which is updated more frequently than that document indicates;
>>
>> rpm --query  --list ca-certificates
>>
>> Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as
>> well as /etc/ssl and /usr/share/pki
>>
>>
>> I suspect that Debian based systems do something comparable, although I
>> don't have on handy to chack.
>>
>>
>> So, short answer: use the system tools to update.  Lets not make an end
>> run around system security.  A config value is another path to Audit.
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Monty Taylor]

On 11/15/2015 10:26 AM, Adam Young wrote:

On 11/14/2015 03:09 AM, Xav Paice wrote:

Hi,

I'm sure I'm not the only one that likes to use SSL everywhere
possible, and doesn't like to pay for 'real' ssl certs for dev
environments.  Figuring out how to get requests to allow connection to
the self signed cert would have paid for a real cert many times over.

When I use an SSL cert with a CA not in the Mozilla bundle, and use
keystonemiddleware to access Keystone endpoints, the ssl verification
rightly fails.  It turns out requests doesn't use the system ca cert
bundle, but has it's own.  It's also got a nice easy config option to
set which ca cert bundle you want to use -
http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification

How do people feel about having that as a config option set somewhere,
so we can specify a ca cert in, say, heat.conf, so that we can
continue with the self signed certs of cheapness without needing to
hack up the cacert.pem that comes with requests, or find a way to pass
in environment variables?

Am I barking up the wrong tree here?  How would I go about writing a
blueprint for this, and for which project?  I guess it's something
that would need to be added to all the projects in the
keystone_authtoken section?  Or is there a central place where common
configs like this can live?



I would say that the right approach is to add the CA to the system
bundle for the calling machine.  Requests not using the System defaults
is a Bug.



Installing CAs into the system is easy, but it might take a little while 
to find the magic incantation:


On Debian derived systems:

- Copy the cert to /usr/local/share/ca-certificates
- Execute /usr/sbin/update-ca-certificates

On RedHat derived systems:

- Copy the cert to /etc/pki/ca-trust/source/anchors
- Execute /usr/bin/update-ca-trust extract



I suspect that the reason that they do this is the unwillingness of the
Requests developers to have to battle NSS: The Dogtag developers have a
write up including the steps necessary to get NSS support into Requests.
http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API


On a Fedora system, the python-requests RPM depends on ca-certificates,
which is updated more frequently than that document indicates;

rpm --query  --list ca-certificates

Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as
well as /etc/ssl and /usr/share/pki


I suspect that Debian based systems do something comparable, although I
don't have on handy to chack.


So, short answer: use the system tools to update.  Lets not make an end
run around system security.  A config value is another path to Audit.











__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All] Use of self signed certs in endpoints

[Adam Young]

On 11/14/2015 03:09 AM, Xav Paice wrote:

Hi,

I'm sure I'm not the only one that likes to use SSL everywhere 
possible, and doesn't like to pay for 'real' ssl certs for dev 
environments.  Figuring out how to get requests to allow connection to 
the self signed cert would have paid for a real cert many times over.


When I use an SSL cert with a CA not in the Mozilla bundle, and use 
keystonemiddleware to access Keystone endpoints, the ssl verification 
rightly fails.  It turns out requests doesn't use the system ca cert 
bundle, but has it's own.  It's also got a nice easy config option to 
set which ca cert bundle you want to use - 
http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification


How do people feel about having that as a config option set somewhere, 
so we can specify a ca cert in, say, heat.conf, so that we can 
continue with the self signed certs of cheapness without needing to 
hack up the cacert.pem that comes with requests, or find a way to pass 
in environment variables?


Am I barking up the wrong tree here?  How would I go about writing a 
blueprint for this, and for which project?  I guess it's something 
that would need to be added to all the projects in the 
keystone_authtoken section?  Or is there a central place where common 
configs like this can live?



I would say that the right approach is to add the CA to the system 
bundle for the calling machine.  Requests not using the System defaults 
is a Bug.


I suspect that the reason that they do this is the unwillingness of the 
Requests developers to have to battle NSS: The Dogtag developers have a 
write up including the steps necessary to get NSS support into Requests. 
http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API



On a Fedora system, the python-requests RPM depends on ca-certificates, 
which is updated more frequently than that document indicates;


rpm --query  --list ca-certificates

Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as 
well as /etc/ssl and /usr/share/pki



I suspect that Debian based systems do something comparable, although I 
don't have on handy to chack.



So, short answer: use the system tools to update.  Lets not make an end 
run around system security.  A config value is another path to Audit.












__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [All] Use of self signed certs in endpoints

[Xav Paice]

Hi,

I'm sure I'm not the only one that likes to use SSL everywhere possible,
and doesn't like to pay for 'real' ssl certs for dev environments.
Figuring out how to get requests to allow connection to the self signed
cert would have paid for a real cert many times over.

When I use an SSL cert with a CA not in the Mozilla bundle, and use
keystonemiddleware to access Keystone endpoints, the ssl verification
rightly fails.  It turns out requests doesn't use the system ca cert
bundle, but has it's own.  It's also got a nice easy config option to set
which ca cert bundle you want to use -
http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification

How do people feel about having that as a config option set somewhere, so
we can specify a ca cert in, say, heat.conf, so that we can continue with
the self signed certs of cheapness without needing to hack up the
cacert.pem that comes with requests, or find a way to pass in environment
variables?

Am I barking up the wrong tree here?  How would I go about writing a
blueprint for this, and for which project?  I guess it's something that
would need to be added to all the projects in the keystone_authtoken
section?  Or is there a central place where common configs like this can
live?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev