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