Description of problem: Simple undercloud installation with a very basic certificate does succeed (and then there are warnings BZ#1242675) Trying to create an SSL certificate where the address of the host and endpoints is in the subjectAltNames field and not in the CN, as per the RFC, doesn't go through at all. After the deployment fails, the logs show none of the https endpoints actually up and working. Version-Release number of selected component (if applicable): tested on 2016-01-18.3 and Y2 2015-12-16.1 How reproducible: always Steps to Reproduce: sudo yum -y install crudini sudo crudini --set /etc/pki/tls/openssl.cnf " alternate_names " DNS.1 instack.localdomain sudo crudini --set /etc/pki/tls/openssl.cnf " alternate_names " DNS.2 instack sudo crudini --set /etc/pki/tls/openssl.cnf " alternate_names " DNS.3 192.0.2.2 sudo crudini --set /etc/pki/tls/openssl.cnf " alternate_names " DNS.4 192.0.2.1 sudo crudini --set /etc/pki/tls/openssl.cnf " alternate_names " IP.1 192.0.2.2sudo crudini --set /etc/pki/tls/openssl.cnf " alternate_names " IP.2 192.0.2.1 sudo crudini --set /etc/pki/tls/openssl.cnf " v3_ca " subjectAltName "@alternate_names" sudo crudini --set /etc/pki/tls/openssl.cnf " v3_ca " keyUsage "digitalSignature, keyEncipherment" sudo crudini --set /etc/pki/tls/openssl.cnf " CA_default " copy_extensions copy openssl genrsa -out /home/stack/privkey.pem 2048 openssl req -new -x509 -key privkey.pem -out cacert.pem -days 365 -subj "/C=CA/ST=GTA/L=Toronto/O=Red HAt/OU=QE/CN=Underclouds R Us" && cat cacert.pem privkey.pem > undercloud.pem sudo mkdir /etc/pki/instack-certs sudo cp ~/undercloud.pem /etc/pki/instack-certs/ && sudo semanage fcontext -a -t etc_t "/etc/pki/instack-certs(/.*)?" && sudo restorecon -R /etc/pki/instack-certs cp /usr/share/instack-undercloud/undercloud.conf.sample /home/stack/undercloud.conf sed -i -e "s#.*undercloud_service_certificate.*#undercloud_service_certificate = /etc/pki/instack-certs/undercloud.pem#" /home/stack/undercloud.conf openstack undercloud install Actual results: deployment fails when it cannot reach keystone over https on port 13000. Expected results: deployment should go through using these certificates Additional info: Tested deploy with UC without SSL and using the same technique to generate the OC certificates, which also failed on timeout connecting to endpoints. All tests done in a virt env
I don't believe this should be a blocker for 7.3. First, it's a problem that has existed since 7.0 and this is the first report I've heard. Second, it doesn't appear to be a problem with how we're configuring anything. It appears to be an issue in the libraries that the OpenStack clients use to implement ssl connectivity, and it's outside our control whether we could get those fixed for 7.3. Third, we don't document deploying with subjectAltName for other reasons, so this is only a problem for people who aren't following our recommended configuration. With all that said, we should fix it because it does appear to be incorrect behavior but I wouldn't hold up a release for it.
We should document the fact that using a self-signed cert an depend on also using a (potentially self-signed) CA.
I don't think this is actually a blocker, but on the other hand, seems to me that it's mostly a validation issue. I did get this error when using a self-signed certificate with subjectAltNames, However, it worked if the certificate with subjectAltNames was not self-signed, but signed by a CA cert. That CA cert could even be self-signed; It doesn't necessarily need to be signed by a trusted CA. I think what this needs instead is just documentation stating this.
Moving to 'NEW' while assigned to the default assignee.
OSP 7 has reached its retirement, please see https://access.redhat.com/errata/RHBA-2018:2362