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.
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. On 16 November 2015 at 04:26, Adam Young <ayo...@redhat.com> wrote: > On 11/14/2015 03:09 AM, Xav Paice 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? > > > > 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. > > 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. > http://pki.fedoraproject.org/wiki/Support_NSSDB_in_Python_API > > > On a Fedora system, the python-requests RPM depends on ca-certificates, > which is updated more frequently than that document indicates; > > rpm --query --list ca-certificates > > Shows that it manages the /ec/pki/[ca-trust java tls ] subdirectoies as > well as /etc/ssl and /usr/share/pki > > > I suspect that Debian based systems do something comparable, although I > don't have on handy to chack. > > > 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. > > > > > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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