SSL cert and key options do not work with multiple VIPs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Keystone Charm |
Fix Released
|
High
|
Unassigned | ||
OpenStack Swift Proxy Charm |
Fix Released
|
Undecided
|
Unassigned | ||
keystone (Juju Charms Collection) |
Invalid
|
High
|
Unassigned |
Bug Description
We tried enabling the SSL cert and SSL key options in all the Openstack charms.
However, when using multiple networks and multiple VIPs the SSL options generate a certificate per IP address from the management network.
So, you end up with the following files:
$ find /etc/apache2/ssl/
/etc/apache2/ssl/
/etc/apache2/
/etc/apache2/
/etc/apache2/
/etc/apache2/
/etc/apache2/
Where 10.5.0.0/24 is the management network and 10.5.0.114 is the DHCP IP and 10.5.0.205 is the VIP on the same network.
But there is also a public IP on 31.28.88.0/24 and a Public VIP on 31.28.88.12 which have no SSL cert created, but the configuration includes it, so apache2 refuses to restart with the error:
AH00526: Syntax error on line 14 of /etc/apache2/
SSLCertificateFile: file '/etc/apache2/
Action 'configtest' failed.
Line 14 is: SSLCertificateFile /etc/apache2/
Therefore enabling SSL on any of the Openstack Charms with multiple NICs with a VIP for HA is currently broken.
no longer affects: | cinder |
no longer affects: | horizon |
no longer affects: | cinder |
no longer affects: | nova |
Changed in keystone (Juju Charms Collection): | |
status: | Incomplete → New |
Changed in charm-keystone: | |
importance: | Undecided → High |
Changed in keystone (Juju Charms Collection): | |
status: | New → Invalid |
Changed in charm-keystone: | |
status: | New → Triaged |
Groking the code:
def configure_ cert(self, cn=None): join('/ etc/apache2/ ssl/', self.service_ namespace)
mkdir( path=ssl_ dir)
cert_ filename = 'cert_{ }'.format( cn)
key_ filename = 'key_{}'.format(cn)
cert_ filename = 'cert'
key_ filename = 'key'
ssl_dir = os.path.
cert, key = get_cert(cn)
if cn:
else:
A cert and key should be written out for all required CN's - if ssl_cert and ssl_key configuration options are used, the same cert and key will be used for all of them - so you'd need to add SAN's to the cert to cover all endpoint addresses.
I think that this should work - as this is quite an old bug it would be good to confirm