<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/14/2015 03:09 AM, Xav Paice
wrote:<br>
</div>
<blockquote
cite="mid:CAMb5LvqiZaGy7XocLViTkqAK==fBey=oWKpTEd3V3Wa6iM9VGA@mail.gmail.com"
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 moz-do-not-send="true"
href="http://docs.python-requests.org/en/latest/user/advanced/?highlight=ca_bundle#ssl-cert-verification">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>
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 class="moz-txt-link-freetext" href="http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API">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
cite="mid:CAMb5LvqiZaGy7XocLViTkqAK==fBey=oWKpTEd3V3Wa6iM9VGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>