Fork: 0
OpenStack / openstack-caracal-ipv4
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-ipv4 / docs / upstream-bug-draft-dashboard-tls.md
@Jesse Austin Jesse Austin 2 hours ago 2 KB D-072 dashboard TLS repair (executed) + DOCFIX-089 fail-closed check + BUNDLEFIX-011
Raw Blame History

Upstream bug draft -- charm-openstack-dashboard TLS backend on vhost-less address

STATUS: DRAFT for operator submission (Launchpad: charm-openstack-dashboard). Prepared 2026-07-05 from the ops-update-20260705 RCA (repo changelog addendum 15, D-072). ASCII-only. No site secrets: addresses below are RFC1918 lab values.

Title

Multi-space deployment: haproxy https backend rendered on cluster-binding address, which never receives an apache SSL vhost; L4 health check masks the dead TLS path

Affected

charm-openstack-dashboard 2024.1/stable (observed rev 728 and rev 750; render logic identical across both -- charmhelpers get_network_addresses + haproxy context). Reactive charm generation; juju 3.6.

Environment

Charmed OpenStack Caracal (jammy), MAAS spaces deployment. Application bindings: default ('') = space A (admin), cluster = space B (internal), public = space C (provider). hacluster VIPs on all three planes. vault:certificates TLS.

What happens

  • ApacheSSLContext.get_network_addresses() derives SSL vhost addresses from the DEFAULT-binding fallback (private-address) and the PUBLIC binding: vhosts render for the space-A and space-C unit addresses only.
  • The haproxy context renders the https (443) backend server line from the CLUSTER-binding address (space B).
  • Result: haproxy forwards TLS to :433 where apache has NO SSL vhost; apache serves the connection from the non-SSL main server in PLAINTEXT (verified: plain-HTTP GET to :433 answers 200). TLS clients fail handshake (curl exit 35 / 000) on every dashboard VIP.
  • haproxy's check is Layer4-only, so the backend shows UP and nothing alerts.
  • juju status is fully green throughout; the condition is silent from day one.

Expected

Either the SSL vhost set includes every address the charm itself renders as an HTTPS backend target, or the https backend uses an address from the vhost set (default-binding address), or the health check is HTTPS-aware so the breakage is at least visible.

Workaround

Bind cluster to the same space as the application default binding. Verified: backends re-render onto a vhost-served address and VIP https serves immediately.

Evidence trail (available on request)

charm rev 728 vs 750 full diff (no vhost-logic change); charmhelpers get_network_addresses trail log (LP:1952414 style) showing identical tuple sets across 2800+ renders since deploy; apache2ctl -S vhost list vs haproxy.cfg backend; plaintext-200-on-ssl-port probe; post-rebind verification.