legacy ssl config parameters missing

[José Pekkarinen]

Hi,

I'm testing the charm, and I find the legacy ssl parameters
are not in place, difficulting the task to deploy ussuri using
a wildcard certificate without vault.

Thanks!

José.

[Alex Kavanagh (ajkavanagh)]

I'm fairly certain that the ovn charms are designed to use vault; i.e. they aren't designed for a use case without vault being included. Marking as wishlist.

[José Pekkarinen (koalinux)]

Thanks for the comment, I understand it, it's though the case that often
we are not allowed to have a root CA for certificate signing, so it's not
going to take long when we hit a case that we require to provide ussuri +
ovn for a deployment that relies in a wildcard cert across all services,
so I opened this bug in the charms related.

José.

[Frode Nordahl (fnordahl)]

Note that OVN uses PKI for authentication/authorization and checks the contents of the CN against the name the chassis presents itself with.

Subsequently using a wildcard certificate is not an option.

[José Pekkarinen (koalinux)]

So in the case when we are handed over a wildcard certificate and
customer explicitly ask us not to use vault for certificate handling,
what should be our answer? We don't provide ovn, or we provide it
by other means?

[Frode Nordahl (fnordahl)]

To elaborate a bit on what is involved here, as eluded to in #3 OVN's means of authentication is comprised of 1) checking the authenticity of the certificate chassis present combined with 2) checking that the CN in the certificate matches the FQDN of the connected chassis.

This in turn means that each individual chassis unit in a model requires a different certificate for successful operation of the cluster.

The ssl_* configuration options and the code associated with them was not designed for this. So we currently have no config-based approach to solving this problem for the OVN charms.