OpenStack charms ignores IPv4 VIP when requesting TLS certificates from Vault
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
charms.openstack |
New
|
Undecided
|
Unassigned |
Bug Description
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/
{"versions": {"values": [{"id": "v3.14", "status": "stable", "updated": "2020-04-
```
However, when trying to connect to the Public API endpoint, we got this:
```
curl --cacert ./secrets/
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:
{"sans": ["2001:
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.
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).