# 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 <space-B-addr>: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.