<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 November 2015 at 19:09, Xav Paice <span dir="ltr"><<a href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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 - <a href="http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification" target="_blank">http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification</a></div><div><br></div><div>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?</div><div><br></div><div>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?</div></div></blockquote><div> </div><div>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. <br><br></div><div>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. <br><br></div><div>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. <br><br></div><div>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. <br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>