enforce_ssl redirects to IP address, not hostname

Bug #1689882 reported by Daniel Axtens
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard Charm
Fix Released
Undecided
Daniel Axtens

Bug Description

If enforce_ssl is set to true in openstack-dashboard, a user is redirected to the IP address of the server, not its hostname.

This is easy to reproduce:

1. Generate a self-signed ssl certs with : openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes
2. Set ssl_cert and ssl_key values via

# juju set openstack-dashboard ssl_cert="$(cat cert.pem | base64)"
# juju set openstack-dashboard ssl_key="$(cat key.pem | base64)"

3. I set domain names for the horizon for testing purposes via

juju set openstack-dashboard os-public-hostname="openstack.<my hostname>"

4. I set the /etc/hosts appropriately so I verify that http://openstack.<my hostname> can be accessed

5. Set enforce-ssl to True to redirect http -> https

6. Access http://openstack.<my hostname> again, and observe that I'm redirected to https://<IP> rather than https://openstack.<my hostname>

I expect to be redirected to a hostname, not an IP.

This boils down to the template used to construct the site:

{% if ssl_addr -%}
  RedirectPermanent / https://{{ ssl_addr }}:443/
{%- endif %}

ssl_addr is set in horizon_context.py, and is always an IP address:

                if config('vip'):
                    addr = config('vip')
                elif config('prefer-ipv6'):
                    addr = format_ipv6_addr(get_ipv6_addr()[0])
                else:
                    addr = get_host_ip(unit_get('private-address'))

This is part of an odd quirk whereby the openstack-dashboard doesn't use the standard https tooling but does its own. This means that it only supports one SSL certificate. Presumably this one hostname should represent the public hostname/interface.

This is related to but not quite the same as https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1664954 - that was specifically about multiple VIPs - this is specifically about redirection to an IP.

Daniel Axtens (daxtens)
Changed in charm-openstack-dashboard:
assignee: nobody → Daniel Axtens (daxtens)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-openstack-dashboard (master)

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

Changed in charm-openstack-dashboard:
status: New → In Progress
Revision history for this message
James Hebden (ec0) wrote :

Faced this when using third party certificates with only hostname in the subjectName.
Public hostname was set on the charm, however the rendered HTTPS vhost redirects to the VIP configured, or the private IP of the unit when the VIP is not configured.

Change I made to get this working is here - https://git.launchpad.net/~jhebden/charm-openstack-dashboard/commit/?h=onsite-fixes-17.02&id=214fe0b5f18de13bfc30db9a9046d6a7598c3957

Could probably use a more generate conditional than `if (ssl_addr)` to control the redirect.

JuanJo Ciarlante (jjo)
tags: added: canonical-bootstack
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-openstack-dashboard (master)

Reviewed: https://review.openstack.org/463850
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=51b099c79e4fed72a013f89bb697137b1b794bf7
Submitter: Jenkins
Branch: master

commit 51b099c79e4fed72a013f89bb697137b1b794bf7
Author: Daniel Axtens <email address hidden>
Date: Thu May 11 04:41:19 2017 +1000

    Rework enforce_ssl to use host name, not address

    If enforce_ssl is set to true in openstack-dashboard, a user is
    redirected to the IP address of the server, not its hostname.

    This boils down to the template used to construct the site, which
    is always fed an IP address by horizon_context.py.

    Instead of using an IP address, use the result of resolve_address.

    (This is part of an odd quirk whereby the charm doesn't use the
    standard https tooling but does its own. A conversion to standard
    tooling would be required for a full fix to #1664954.)

    Closes-Bug: #1689882
    Related-Bug: #1664954
    Change-Id: I93365b75211e3c48d64ba8510898750dbc7b73cd
    Signed-off-by: Daniel Axtens <email address hidden>

Changed in charm-openstack-dashboard:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-openstack-dashboard (stable/17.02)

Fix proposed to branch: stable/17.02
Review: https://review.openstack.org/468255

Ryan Beisner (1chb1n)
tags: added: adrastea
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-openstack-dashboard (stable/17.02)

Reviewed: https://review.openstack.org/468255
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=f4c8cadd4caa6a21f8511b3f5e4d9f1ab404f6cd
Submitter: Jenkins
Branch: stable/17.02

commit f4c8cadd4caa6a21f8511b3f5e4d9f1ab404f6cd
Author: Daniel Axtens <email address hidden>
Date: Thu May 11 04:41:19 2017 +1000

    Rework enforce_ssl to use host name, not address

    If enforce_ssl is set to true in openstack-dashboard, a user is
    redirected to the IP address of the server, not its hostname.

    This boils down to the template used to construct the site, which
    is always fed an IP address by horizon_context.py.

    Instead of using an IP address, use the result of resolve_address.

    (This is part of an odd quirk whereby the charm doesn't use the
    standard https tooling but does its own. A conversion to standard
    tooling would be required for a full fix to #1664954.)

    Closes-Bug: #1689882
    Related-Bug: #1664954
    Change-Id: I93365b75211e3c48d64ba8510898750dbc7b73cd
    Signed-off-by: Daniel Axtens <email address hidden>
    (cherry picked from commit 51b099c79e4fed72a013f89bb697137b1b794bf7)

James Page (james-page)
Changed in charm-openstack-dashboard:
milestone: none → 17.08
James Page (james-page)
Changed in charm-openstack-dashboard:
status: Fix Committed → Fix Released
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.