Description of problem: Cloned from upstream bug https://bugs.launchpad.net/tripleo/+bug/1639807 When installing the undercloud with SSL, the default is to create a self-signed certificate, see 'generate_service_certificate' and 'certificate_generation_ca': https://github.com/openstack/instack-undercloud/blob/0fa4ab/undercloud.conf.sample#L44 Unfortunately this is causing issues from the UI's perspective, particularly when using Firefox as the browser has gotten stricter with regard to self-signed certificates. This means that not only an "insecure connection (SEC_ERROR_UNKNOWN_ISSUER)" exception that needs to be manually accepted is displayed on the login page, but the certificate needs to be accepted for every single service as well (i.e. one cannot connect to keystone until the cert has been accepted manually for the service's URL there). This is cumbersome. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Blocker flag since it's required for GA to support Firefox browser
Anandeep what is the next step for this?
The approach upstream at the moment seems to be to improve the CA cert created, so that Firefox can accept and recognise the self-signed certificate later on. We'll likely still need something like a documentation note to let users know how to import the certificate in Firefox. (Dan Trainor can add more information if I'm misunderstanding things.)
(copying in from lp bug) Did a lot more investigation in to this. Turns out, even with the CA used by certmonger (/etc/pki/ca-trust/source/anchors/cm-local-ca.pem) imported in to Firefox, we still see exceptions when connecting to SSL endpoints on nonstandard HTTP ports (e.g. anything not :443). That has to do with: https://bugzilla.mozilla.org/show_bug.cgi?id=700837 It doesn't appear that they're too interested in changing this behavior, either. The only way I was able to make the UI work in Firefox is by allowing exceptions to each endpoint that UI would communicate with. This is preformed via Options -> Preferences -> Advanced -> View Certificates -> Server, clicking the "Add Exception" button on the bottom, and adding an exception for each of: http://<undercloud>:13000 http://<undercloud>:13004 http://<undercloud>:13385 http://<undercloud>:13989 http://<undercloud>:13808 http://<undercloud>:9000
Workarounds found by Dan Trainor are what we will be using for OSP 10, need to revisit in Ocata for Server Proxy based solution. Not a blocker.
Do we need to open a separate docs bug to track including the workaround in the documentation for OSP10, or is this handled separately?
Removing my needinfo as I see this is already included in the beta documentation. (Awesome!)
Any progress on this?
We have reconfigured the way that UI makes connections to each backend service. Previously, the UI made connections to each individual backend service on its own respective port, e.g. http(s)://undercloud:13000 for keystone, http(s)://undercloud:9000 for zaqar etc. Now[0], each connection is made to http(s)://undercloud/{servicename}, e.g. http(s)://undercloud:443/keystone. This was done to avoid what we were seeing in comment #5. --- [0] https://blueprints.launchpad.net/tripleo/+spec/proxy-undercloud-api-services
Works in puppet-tripleo-6.3.0-6.el7ost.noarch
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-2017:1245