Bug 1392627

Summary:	Can't login to the UI with SSL when using Firefox
Product:	Red Hat OpenStack	Reporter:	Ola Pavlenko <opavlenk>
Component:	puppet-tripleo	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED ERRATA	QA Contact:	nlevinki <nlevinki>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	apannu, dtrainor, jjoyce, jpichon, jrist, jschluet, opavlenk, racedoro, slinaber, tvignaud, vcojot
Target Milestone:	rc	Keywords:	Triaged
Target Release:	11.0 (Ocata)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	puppet-tripleo-6.3.0-6.el7ost.noarch	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1465644 (view as bug list)		Environment:
Last Closed:	2017-05-17 19:37:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1465644

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