OpenStack charms ignores IPv4 VIP when requesting TLS certificates from Vault

[Claudiu Belu]

In a recent deployment of an OpenStack Yoga bundle, we've experienced an issue with the certificates generated for all the OpenStack components.

In this scenario, we've configured Keystone with 2 VIPs, one for the OpenStack Internal API (10.10.22.70) and one for the OpenStack Public API (10.10.27.70):

```
$ juju config keystone vip
10.10.27.70 10.10.22.70
```

The expectation was that, through the relation with Vault, the certificates would be generated properly. For the Internal API, it worked as intended:

```
curl --cacert ./secrets/tls/openstack.crt https://10.10.22.70:5000
 {"versions": {"values": [{"id": "v3.14", "status": "stable", "updated": "2020-04-07T00:00:00Z", "links": [{"rel": "self", "href": "https://keystone.openstack.mycloud:5000/v3/"}], "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}]}]}}
```

However, when trying to connect to the Public API endpoint, we got this:

```
curl --cacert ./secrets/tls/openstack.crt https://10.10.27.70:5000
curl: (35) error:0A00010B:SSL routines::wrong version number
```

Looking at the Vault relation data from keystone, we see the following:

```
related-units:
   keystone/0:
     in-scope: true
     data:
       cert_requests: '{"eth2.juju-9e0ad0-0-lxd-7.maas": {"sans": ["10.10.20.163"]},
         "keystone-internal.openstack.mycloud": {"sans": ["10.10.22.22",
         "10.10.22.70", "keystone-internal.openstack.mycloud"]}, "keystone.openstack.mycloud":
         {"sans": ["2001:470:5300:1027:216:3ffe:cafe:aa79", "keystone.openstack.mycloud"]}}'
       egress-subnets: 10.10.22.22/32
       ingress-address: 10.10.22.22
       private-address: 10.10.22.22
       unit_name: keystone_0

```

As we can see, the unit indeed requested the certificate to be generated for the Internal API VIP, but for the Public API VIP, it chose an IPv6 IP instead of the desired IPv4 IP. That IPv6 IP can be seen on the unit's Public API network. After fetching the "keystone.openstack.mycloud" certificate, we could see that it was signed for "keystone.openstack.mycloud" and the IPv6 IP, which then results in the errors we've seen when accessing Keystone on the Public API network. This applies to all of the OpenStack charms which had an endpoint on the Public API network (and had an IPv6 IP as well).

The OpenStack charms should have at least prioritized the set VIPs when requesting certificates from Vault, or at least request certificates for **all** its IPs (both IPv4 and IPv6).