Open Stack

On 11/16/2015 01:03 AM, Jamie Lennox wrote:
> 
> 
> On 14 November 2015 at 19:09, Xav Paice <xavpaice at gmail.com
> <mailto:xavpaice at gmail.com>> 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