Hide Forgot
We've used the m2crpto load_verify_locations() method to give m2crypto CA paths. Unfortunately with the capath parameter, the given directory must contain PEM certificates with only one certificate per file. This is fine for users who have generated their own CA who want to put that CA off in some random folder. However, on Red Hat based systems all installed CAs go together in one file (even custom generated ones). load_verify_locations() accepts another parameter called cafile that can be a path to a file with multiple CAs in it. In order to work with system installed CAs, we will need to use that directive on Red Hat based systems because that's how Red Hat does things. Unfortunately, many other operating systems (Ubuntu and Gentoo included) do the opposite - they install multiple files into a folder, one certificate per file. I have no idea what m2crypto does if you use both directives, so I'm going to assume that we shouldn't do that. We could give the user access to both settings, but I think that would be confusing. I propose that we do this instead: 1) We keep the ca_path setting, but we allow it to be a path to a directory or to a file, 2) When we are about to use the ca_path setting in m2crypto, we stat it to see which it is (directory or file). If a file, we use m2crypto's cafile directive. If a directory, we use m2crypto's capath directive. If it doesn't exist, we raise an exception (which is handy to catch typos anyway). 3) We document the junk out of this, so it's not confusing for users. We should provide good in-line docs in the files that use it as well as in our Sphinx docs. 4) We default it to /etc/pki/tls/certs/ca-bundle.crt, which contains Red Hat selected certificate authorities all in one file. [0] http://www.heikkitoivonen.net/m2crypto/api/M2Crypto.SSL.Context%27.Context-class.html#load%5Fverify%5Flocations
https://github.com/pulp/pulp/pull/1074
Here are some steps to verify this bug: 1) Set all verify_ssl settings to True (consumer.conf, admin.conf, nodes.conf). 2) Leave ca_path to its default setting (/etc/pki/tls/certs/ca-bundle.crt) 3) Verify that pulp-admin <any command that talks to the server> gives you the ssl warning. 4) Generate a certificate authority certificate and key, and use them to sign Apache's certificates. 5) Copy the CA certificate (not the key!) to /etc/pki/ca-trust/source/anchors/ 6) Run "update-ca-trust extract" as root (this will install the CA to the file at /etc/pki/tls/certs/ca-bundle.crt.) 7) Verify that pulp-admin is now willing to communicate with pulp server with no SSL warnings.
[root@cloud-qe-15 ~]# rpm -qa pulp-server pulp-server-2.4.0-0.30.beta.el6.noarch [root@cloud-qe-15 ~]# [root@cloud-qe-15 ~]# pulp-admin repo list +----------------------------------------------------------------------+ Repositories +----------------------------------------------------------------------+ WARNING: The server's SSL certificate is untrusted! The server's SSL certificate was not signed by a trusted authority. This could be due to a man-in-the-middle attack, or it could be that the Pulp server needs to have its certificate signed by a trusted authority. If you are willing to accept the associated risks, you can set verify_ssl to False in the client config's [server] section to disable this check. [root@cloud-qe-15 ~]# [root@cloud-qe-15 ~]# cp newcerts/ca.crt /etc/pki/ca-trust/source/anchors/ [root@cloud-qe-15 ~]# update-ca-trust enable [root@cloud-qe-15 ~]# update-ca-trust extract [root@cloud-qe-15 ~]# [root@cloud-qe-15 ~]# [root@cloud-qe-15 ~]# pulp-admin repo list +----------------------------------------------------------------------+ Repositories +----------------------------------------------------------------------+ Id: zoo Display Name: zoo Description: None Content Unit Counts: Erratum: 4 Package Category: 1 Package Group: 2 Rpm: 32 [root@cloud-qe-15 ~]#
This has been fixed in Pulp 2.4.0-1.