On 11/15/2015 10:26 AM, Adam Young 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.
Installing CAs into the system is easy, but it might take a little while
to find the magic incantation:
On Debian derived systems:
- Copy the cert to /usr/local/share/ca-certificates
- Execute /usr/sbin/update-ca-certificates
On RedHat derived systems:
- Copy the cert to /etc/pki/ca-trust/source/anchors
- Execute /usr/bin/update-ca-trust extract
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: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
__________________________________________________________________________
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
