Description of problem: ----------------------- While upgrading from RHOS-13 to RHOS-14 generate_service_certificate option from undercloud.conf is set to true by default and generates SSL cert for undercloud. The problem is that if ssl cert already exists it's overwritten, which is wrong. Version-Release number of selected component (if applicable): ------------------------------------------------------------- instack-9.0.1-0.20180530160825.1dca54c.el7ost.noarch instack-undercloud-9.1.1-0.20180716115151.bc82d48.el7ost.noarch openstack-tripleo-heat-templates-9.0.0-0.20180717094150.el7ost.noarch openstack-tripleo-common-containers-9.1.1-0.20180717062358.eee5526.el7ost.noarch python2-tripleo-common-9.1.1-0.20180717062358.eee5526.el7ost.noarch openstack-tripleo-common-9.1.1-0.20180717062358.eee5526.el7ost.noarch How reproducible: ----------------- 100% Steps to Reproduce: ------------------- 1. Deploy RHOS-13 with UC/OC SSL 2. Install RHOS-14 repos on UC/OC, prepare container images 3. Upgrade UC 4. Try to reach keystone's public endpoint from OC nodes Actual results: --------------- [root@compute-0 ~]# curl -v 'https://192.168.24.2:13000' * About to connect() to 192.168.24.2 port 13000 (#0) * Trying 192.168.24.2... * Connected to 192.168.24.2 (192.168.24.2) port 13000 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Server certificate: * subject: CN=192.168.24.2 * start date: Jul 26 13:04:51 2018 GMT * expire date: Jul 26 13:04:50 2019 GMT * common name: 192.168.24.2 * issuer: CN=b43127f7-a1f3436c-bd13e952-f6c4f3a7,CN=Local Signing Authority * NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER) * Peer's certificate issuer has been marked as not trusted by the user. * Closing connection 0 curl: (60) Peer's certificate issuer has been marked as not trusted by the user. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.
Changes merged in build python-tripleoclient-10.5.1-0.20180906012842.el7ost Moving bug to MODIFIED.
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. https://access.redhat.com/errata/RHEA-2019:0045
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days