Can't login to the UI with SSL when using Firefox

Bug #1639807 reported by Julie Pichon
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
High
Juan Antonio Osorio Robles

Bug Description

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.

Revision history for this message
Julie Pichon (jpichon) wrote :

Looking at the comments on undercloud.conf, the new CA authority cert is created at /etc/pki/ca-trust/source/anchors/cm-local-ca.pem so theoretically adding it to the list of trusted CA in Firefox should be sufficient. Unfortunately I'm getting a new error after doing this - SEC_ERROR_EXTENSION_VALUE_INVALID, need to investigate a little bit more.

Revision history for this message
Julie Pichon (jpichon) wrote :

Another option could be to accept self-signed certificates from the UI itself, when the undercloud was installed with SSL and 'local' as a certificate_generation_ca. This is something we could pick up on during the install, and set appropriately from puppet inside the config file. Not entirely sure if the way we contact the different APIs would let us do this though, I'm not familiar enough with that code.

Revision history for this message
Jiri Tomasek (jtomasek) wrote :

First that comes to mind is why using ssl when the certificates end up being self signed.

There appears to be 'rejectUnauthorized' option in server side oriented libraries which handle xmlhttp requests. We currently use reqwest [1] library for handling ajax calls which seems not to provide any of such options (and by looking at other tools such as Fetch it does not seem that it is available anywhere else), but even if such option was available, it would have to be tied to a development environment only.

By doing some investigation, I see there is an option in firefox (an most probably in other browsers too) which allow to automatically accept invalid ssl certificates ([2]) this is obviously very insecure, but it imho matches the insecurity of using self-signed certificates.

I'd probably favor not enabling ssl for installing undercloud for testing purposes. If testing ssl and GUI at once, then mentioned browser option should be probably used.

[1] https://www.npmjs.com/package/reqwest
[2] http://stackoverflow.com/questions/20088/is-there-a-way-to-make-firefox-ignore-invalid-ssl-certificates

Additional links:
http://stackoverflow.com/questions/30902547/websocket-ssl-connection
http://stackoverflow.com/questions/32892161/ignore-errors-for-self-signed-ssl-certs-using-the-fetch-api-in-a-reactnative-app/36368360#36368360

Revision history for this message
Dan Trainor (dtrainor) wrote :

SSL must be enabled for UI to work, since enabling SSL brings in haproxy which we then use to proxy requests to the services which UI calls upon. Agreed, however, that the assumption that using self-signed certificates also means assuming the user knows how to configure their environment (in this case, the browser) to use this self signed certificate. I know that's a difficult line to take but it would also turn people more towards using legitimate SSL certificates from vendors such as LetsEncrypt or using their existing CA infrastructure.

I had suspected that including either/or the root CA or intermediate from the certmonger 'local' CA store we could drop clues to Firefox to tell it how to verify the self-signed certificate but using the CA (/etc/pki/ca-trust/source/anchors/cm-local-ca.pem) would work, but my tests didn't seem to indicate this would work.

Subscribing Juan Antonio Osorio since he knows SSL ins and outs very well and should be able to provide some excellent feedback and options.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to puppet-tripleo (master)

Fix proposed to branch: master
Review: https://review.openstack.org/394793

Changed in tripleo:
assignee: nobody → Juan Antonio Osorio Robles (juan-osorio-robles)
status: Triaged → In Progress
Revision history for this message
Dan Trainor (dtrainor) wrote :

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

Revision history for this message
Dan Trainor (dtrainor) wrote :
Revision history for this message
Dan Trainor (dtrainor) wrote :
Steven Hardy (shardy)
Changed in tripleo:
milestone: ocata-1 → ocata-2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to puppet-tripleo (master)

Reviewed: https://review.openstack.org/394793
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=ffd7040a6dcfda59a6768fbe481aba332133e83a
Submitter: Jenkins
Branch: master

commit ffd7040a6dcfda59a6768fbe481aba332133e83a
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Tue Nov 8 09:05:12 2016 +0200

    Include local CA in haproxy PEM

    In order for the browser to trust the certificate served by HAProxy
    we need to include the CA cert in the PEM file that the endpoints
    serve.

    Change-Id: Ibce76c1aa04bd3cb09a804c6e9789c55d8f2b417
    Closes-Bug: #1639807

Changed in tripleo:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/puppet-tripleo 6.1.0

This issue was fixed in the openstack/puppet-tripleo 6.1.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to puppet-tripleo (stable/newton)

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/478310

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to puppet-tripleo (stable/newton)

Reviewed: https://review.openstack.org/478310
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=57c4a526445144b6d006abbcc1b206b0a6f8403b
Submitter: Jenkins
Branch: stable/newton

commit 57c4a526445144b6d006abbcc1b206b0a6f8403b
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Tue Nov 8 09:05:12 2016 +0200

    Include local CA in haproxy PEM

    In order for the browser to trust the certificate served by HAProxy
    we need to include the CA cert in the PEM file that the endpoints
    serve.

    Change-Id: Ibce76c1aa04bd3cb09a804c6e9789c55d8f2b417
    Closes-Bug: #1639807
    (cherry picked from commit ffd7040a6dcfda59a6768fbe481aba332133e83a)

tags: added: in-stable-newton
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/puppet-tripleo 5.6.1

This issue was fixed in the openstack/puppet-tripleo 5.6.1 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.