Bug 1300452 - When deploying the undercloud and overcloud with an SSL certificate that contains subjectAltNames, the deployment fails
When deploying the undercloud and overcloud with an SSL certificate that cont...
Status: NEW
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
7.0 (Kilo)
x86_64 Linux
high Severity medium
: y3
: 7.0 (Kilo)
Assigned To: RHOS Documentation Team
RHOS Documentation Team
: Documentation, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-20 16:01 EST by Dan Yasny
Modified: 2017-09-11 22:09 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Yasny 2016-01-20 16:01:48 EST
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
Comment 1 Ben Nemec 2016-01-25 14:20:48 EST
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.
Comment 2 Angus Thomas 2016-01-27 04:56:48 EST
We should document the fact that using a self-signed cert an depend on also using a (potentially self-signed) CA.
Comment 3 Juan Antonio Osorio 2016-01-27 08:23:04 EST
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.
Comment 4 Andrew Dahms 2016-08-08 08:19:45 EDT
Moving to 'NEW' while assigned to the default assignee.

Note You need to log in before you can comment on or make changes to this bug.