Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport CA and certificate fixes to 4.5.0.z #347

Merged
merged 12 commits into from
May 9, 2022

Conversation

Currently our internal CA is always issued for 10 years during the
initial engine-setup. This carries over upgrades and on old enough
installations we can get close to expiration. We don't have an easy way
how to replace internal CA without complete downtime, and running over
the expiration date leads to a complete cease of communication between
all oVirt components.

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=2079799
mz-pdm and others added 11 commits May 9, 2022 15:28
Non-web certificates are not subjects to the lifetime limitations
required by web browsers.  VDS certificates must be renewed when the
host is in maintenance, which makes frequent upgrades difficult.
Let’s extend the lifetime of non-web certificates to 5 years (a value
selected by Michal) to make the certificate updates much less
frequent.

Bug-Url: https://bugzilla.redhat.com/2079835
…host-upgrade

Otherwise the whole playbook will stop immediately and host upgrade
fails.  We want to proceed instead and update the certificates.

Bug-Url: https://bugzilla.redhat.com/2079890
Currently, we warn about host certificate expiration 120 days in
advance and alert and perform renewal on host upgrades 30 days in
advance.  These proved to be too late, many users don’t pay
appropriate attention to warnings and alerts and when there is no host
upgrade during the relatively short period, the users may end up with
expired certificates and non-responsive hosts.

Now, when we have extended the lifetime of host certificates to 3650
days, we can warn about host certificate expiration earlier and force
renewal on host upgrades already during the warning period.  This
increases the chances there will be a host upgrade (with certificate
renewal) during the period.  Value of CertExpirationWarnPeriodInDays
is increased to 365.

This change also extends the warning period for all other certificates
except for web certificates.

Bug-Url: https://bugzilla.redhat.com/2079890
When a host certificate expires the host becomes non-responsive.
There is no longer a way to connect to the host via the Vdsm API.
But it would be still possible to renew the certificate if the
operation wasn’t blocked in the web UI.  Let’s permit enrolling
certificates from the menu also for hosts in non-responsive state, to
make life easier for users who ignore warning about upcoming
certificate expiration until it actually happens.

Of course, a host can become non-responsive also for other reasons
than its certificate expiration.  If the users decide to renew
certificates in such states, it’s their own decision and risk.
A host in such a state is not in a good shape anyway and restarting
the services running on it, as needed by the certificate renewal, is
not that much an issue.

Bug-Url: https://bugzilla.redhat.com/2079901
OVN services are not restarted after OVN certificate update.
Unlike other services, which are restarted after enrolling
certificates, these ones are not restarted together with libvirtd
restart and need their own restart action.

Bug-Url: https://bugzilla.redhat.com/2079901
After updating Vdsm certificates, the corresponding services are not
restarted.  Or, actually, they are, but only as a part of
ovirt-host-deploy-vnc-certificates role if those certificates happened
to be updated as well (they usually do), which is not entirely
sufficient.  And ovirt-imageio is not restarted at all.

Let’s make sure the services are always restarted after Vdsm
certificates update.  It’s sufficient to restart libvirtd (it restarts
vdsmd etc. too) and ovirt-imageio (vdsmd wants it started but doesn’t
ensure its restart).

We check for both ‘enabled’ status and ‘running’ states.  Some
services may be stopped before updates, so checking for ‘running’
wouldn’t be sufficient.  And ovirt-imageio may be running but not
enabled, which is probably a bug but it doesn’t harm to check for
both.

This change also means that some services may be restarted more than
once during a certificate update.  Fixing this would need introducing
inter-role service handling, which would be too complicated at the
moment.  Multiple restarts should be usually harmless because this is
normally done in the maintenance mode.

Bug-Url: https://bugzilla.redhat.com/2079901
Expose VdsCertificateValidityInDays in engine-config to allow to set
custom validity period of hypervisor certificates.

Bug-Url: https://bugzilla.redhat.com/2079890
Non-web certificates are not subjects to the lifetime limitations
required by web browsers.  Let’s extend the lifetime of non-web Engine
certificates to 5 years (the same value as for the host certificates)
to make the certificate updates much less frequent.

Let’s also drop the check for long certificate lifetime.  All web
certificates should already have the shortened lifetime, otherwise
they wouldn’t work with current browsers.

Bug-Url: https://bugzilla.redhat.com/2079835
Checks for vmconsole-proxy-host and vmconsole-proxy-user certificates
status were missing, resulting in those certificates not renewed when
needed.  This patch adds the missing checks.

Bug-Url: https://bugzilla.redhat.com/2066084
@michalskrivanek michalskrivanek changed the title issue internal CA for 20 years Backport CA and certificate fixes to 4.5.0.z May 9, 2022
@michalskrivanek michalskrivanek merged commit 32db36f into ovirt-engine-4.5.0.z May 9, 2022
@sandrobonazzola sandrobonazzola deleted the backport-ca branch May 11, 2022 07:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants