Comment 6 for bug 1711360

I tried replicating this in serverstack, but was unable to do so. Both the ssl files and the apache config used the canonical host name to name things.

Here's what I did to set things up:

1) I created three virtual networks via the openstack networking tools, and attached them to the machines that I was going to deploy charms to.

2) I deployed a minimal set of charms: glance, with keystone, rabbitmq-server and percona-cluster.

3) I deployed glance and configured it like so:

juju config glance \
     ssl_cert="$( base64 juju-d0e9cf-petevg-13.openstacklocal.crt )" ssl_key="$( base64 juju-d0e9cf-petevg-13.openstacklocal.key )" \
     os-public-network=10.6.3.0/24 os-admin-network=10.6.3.0/24 os-internal-network=192.168.23.0/24 \
     os-admin-hostname=juju-d0e9cf-petevg-13.openstacklocal os-internal-hostname=juju-d0e9cf-petevg-13.openstacklocal \
     os-public-hostname=juju-d0e9cf-petevg-13.openstacklocal \
     vip='192.168.X.Y 10.6.4.X'

Apache successfully starts, with ssl cert filenames that match the names and paths in the apache config.

I think that the codepath in charmhelpers is slightly different when it writes out the ssl certs and when it writes the apache config. When writing the ssl certs, it gets a list of canonical names, and writes out matching certs. When it writes out the config, it starts with a list of IPs, and overrides the IP of the endpoint if it has a canonical name for it. If the latter path breaks due to an issue with DNS, then you would see the behavior in the bug: the ssl cert gets tagged with the canonical name, but the apache config references the IP.

I would double check the DNS setup in the environment, and see if fixing it fixes this bug. If not, please re-open, and I will dig further into the issue.