Bug 1610246

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.