Description of problem: When setting up an SSL-enabled Keystone environment, the quantum client fails to verify a certificate, even though the OS_CACERT variable is correctly set to the CA certificate. I have performed some troubleshooting, and it looks like the variable is ignored by the client, and it simply opens /etc/ssl/certs/ca-bundle.crt to look for the CA certificates. https://review.openstack.org/#/c/24776/ is the upstream fix. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Setup Keystone to use SSL. 2. export OS_CACERT=<path to CA certificate> 3. Run the quantum client (e.g. quantum net-list) Actual results: SSL certificate validation error Expected results: no SSL certificate validation errors. Additional info:
A workaround is to manually add the CA certificate to /etc/ssl/certs/ca-bundle.crt, doing something like: openssl x509 -in /etc/pki/CA/certs/ca.crt -text >> /etc/ssl/certs/ca-bundle.crt However, any package update could break this again, I guess.
The upstream fix mentioned is included in python-neutronclient >= 2.2.5 so this should be fixed in current version.
Auto adding >= MODIFIED bugs to beta
Would you please add steps for Keystone with SSL configuration - especially on how to create all certs and keys files?
The steps followed were: 1- Create an openssl.cnf file with the following contents: [ req ] default_bits = 2048 default_keyfile = keystonekey.pem default_md = default req_extensions = v3_req prompt = no distinguished_name = distinguished_name [ distinguished_name ] countryName = ES stateOrProvinceName = MA localityName = Madrid organizationName = OrgName organizationalUnitName = OrgUnit commonName = loadbalancer.internal.example.com [v3_req] keyUsage = keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.2 = server1.internal.example.com DNS.3 = server2.internal.example.com DNS.4 = loadbalancer.external.example.com DNS.5 = loadbalancer.internal.example.com IP.1 = 10.26.236.249 IP.2 = 10.26.238.217 IP.3 = 10.26.238.243 IP.4 = 10.26.238.244 2- Generate CSR openssl req -newkey rsa:2048 -keyout signing_key.pem -keyform PEM -out signing_cert_req.pem -outform PEM -config openssl.conf -nodes 3- In this case, we were using a Microsoft CA, so I just uploaded the CSR and generated a new signed certificate, using a "Web Server" certificate template. I have not tested other cases, but http://www.devsec.org/info/ssl-cert.html seems to provide easy to follow steps for OpenSSL signing. 4- Download the generated certificate in PEM format and place it in the path specified by the configuration file (in our case, /etc/pki/tls/certs/ost-keystone.pem for the certificate and /etc/pki/tls/private/ost-keystone.pem for the private key, generated in step 2).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days