<div dir="ltr">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 <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-11-12.log.html#t2015-11-12T18:20:05">http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-11-12.log.html#t2015-11-12T18:20:05</a> as well, some good discussion going on.<div><br></div><div>cc'ing Clark specifically since he was so helpful in getting this thing sorted.</div><div><br></div><div><br></div><div>So the consensus here is to discuss using the system CAs with the requests devs rather than add a config item to OpenStack?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 November 2015 at 05:14, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/15/2015 10:26 AM, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/14/2015 03:09 AM, Xav Paice wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I'm sure I'm not the only one that likes to use SSL everywhere<br>
possible, and doesn't like to pay for 'real' ssl certs for dev<br>
environments. Figuring out how to get requests to allow connection to<br>
the self signed cert would have paid for a real cert many times over.<br>
<br>
When I use an SSL cert with a CA not in the Mozilla bundle, and use<br>
keystonemiddleware to access Keystone endpoints, the ssl verification<br>
rightly fails. It turns out requests doesn't use the system ca cert<br>
bundle, but has it's own. It's also got a nice easy config option to<br>
set which ca cert bundle you want to use -<br>
<a href="http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification" rel="noreferrer" target="_blank">http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification</a><br>
<br>
How do people feel about having that as a config option set somewhere,<br>
so we can specify a ca cert in, say, heat.conf, so that we can<br>
continue with the self signed certs of cheapness without needing to<br>
hack up the cacert.pem that comes with requests, or find a way to pass<br>
in environment variables?<br>
<br>
Am I barking up the wrong tree here? How would I go about writing a<br>
blueprint for this, and for which project? I guess it's something<br>
that would need to be added to all the projects in the<br>
keystone_authtoken section? Or is there a central place where common<br>
configs like this can live?<br>
</blockquote>
<br>
<br>
I would say that the right approach is to add the CA to the system<br>
bundle for the calling machine. Requests not using the System defaults<br>
is a Bug.<br>
</blockquote>
<br>
<br></div></div>
Installing CAs into the system is easy, but it might take a little while to find the magic incantation:<br>
<br>
On Debian derived systems:<br>
<br>
- Copy the cert to /usr/local/share/ca-certificates<br>
- Execute /usr/sbin/update-ca-certificates<br>
<br>
On RedHat derived systems:<br>
<br>
- Copy the cert to /etc/pki/ca-trust/source/anchors<br>
- Execute /usr/bin/update-ca-trust extract<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect that the reason that they do this is the unwillingness of the<br>
Requests developers to have to battle NSS: The Dogtag developers have a<br>
write up including the steps necessary to get NSS support into Requests.<br>
<a href="http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API" rel="noreferrer" target="_blank">http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API</a><br>
<br>
<br>
On a Fedora system, the python-requests RPM depends on ca-certificates,<br>
which is updated more frequently than that document indicates;<br>
<br>
rpm --query --list ca-certificates<br>
<br>
Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as<br>
well as /etc/ssl and /usr/share/pki<br>
<br>
<br>
I suspect that Debian based systems do something comparable, although I<br>
don't have on handy to chack.<br>
<br>
<br>
So, short answer: use the system tools to update. Lets not make an end<br>
run around system security. A config value is another path to Audit.<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
<a href="http://Unsubscribe:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">Unsubscribe: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>
</blockquote>
<br>
<br>
<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>
<br>
<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>
</div></div></blockquote></div><br></div>