Bug 1392627 - Can't login to the UI with SSL when using Firefox
Summary: Can't login to the UI with SSL when using Firefox
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: puppet-tripleo
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 11.0 (Ocata)
Assignee: RHOS Maint
QA Contact: nlevinki
URL:
Whiteboard:
Depends On:
Blocks: 1465644
TreeView+ depends on / blocked
 
Reported: 2016-11-07 22:30 UTC by Ola Pavlenko
Modified: 2018-02-11 15:35 UTC (History)
11 users (show)

Fixed In Version: puppet-tripleo-6.3.0-6.el7ost.noarch
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1465644 (view as bug list)
Environment:
Last Closed: 2017-05-17 19:37:56 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1245 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 23:01:50 UTC
Launchpad 1639807 None None None 2016-11-07 22:31:30 UTC

Description Ola Pavlenko 2016-11-07 22:30:31 UTC
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:

Comment 1 Ola Pavlenko 2016-11-07 22:31:31 UTC
Blocker flag since it's required for GA to support Firefox browser

Comment 3 Jason E. Rist 2016-11-07 23:57:10 UTC
Anandeep what is the next step for this?

Comment 4 Julie Pichon 2016-11-08 08:46:15 UTC
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.)

Comment 5 Dan Trainor 2016-11-09 19:12:33 UTC
(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

Comment 6 Anandeep Pannu 2016-11-15 15:30:25 UTC
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.

Comment 7 Anandeep Pannu 2016-11-15 15:30:42 UTC
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.

Comment 8 Julie Pichon 2016-11-22 10:29:17 UTC
Do we need to open a separate docs bug to track including the workaround in the documentation for OSP10, or is this handled separately?

Comment 9 Julie Pichon 2016-11-28 11:09:45 UTC
Removing my needinfo as I see this is already included in the beta documentation. (Awesome!)

Comment 10 Jason E. Rist 2017-03-29 14:31:37 UTC
Any progress on this?

Comment 11 Dan Trainor 2017-04-11 16:16:23 UTC
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

Comment 12 Dan Trainor 2017-04-11 16:29:07 UTC
Works in puppet-tripleo-6.3.0-6.el7ost.noarch

Comment 15 errata-xmlrpc 2017-05-17 19:37:56 UTC
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


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