<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 November 2015 at 04:26, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div>On 11/14/2015 03:09 AM, Xav Paice
wrote:<br>
</div>
<blockquote type="cite">
<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>
<br>
<br></div></div>
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.<br>
<br>
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.
<a href="http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API" 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, 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 well as /etc/ssl and /usr/share/pki<br>
<br>
<br>
I suspect that Debian based systems do something comparable,
although I don't have on handy to chack.<br>
<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</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>