3:29 p.m.
Hi Team,
we are using a custom certificate on the engine apache GUI
/etc/pki/ovirt-engine/certs/apache.cer (following
https://myhomelab.gr/linux/2020/01/20/replacing_ovirt_ssl.html) and it works fine. The
certificate is valid for a very long period.
It seems the vdsm certificate (/etc/pki/vdsm/certs/vdsmcert.pem), on hosts side, has been
renewed automatically at that time, but for only one year.
Now we wonder, what will happen when the vdsm certificate will expire? hosts will stop to
be in the cluster? if yes what should we do to avoid that? is there a possibility to also
apply our custom cert as vdsm cert?
This is for ovirt 4.4 running on rhel8
thx a lot in advance
5:36 p.m.
Hi,
On Thu, Dec 15, 2022 at 3:29 PM Vinz Vinz <vk(a)itiviti.com> wrote:
Hi Team,
we are using a custom certificate on the engine apache GUI
/etc/pki/ovirt-engine/certs/apache.cer (following
https://myhomelab.gr/linux/2020/01/20/replacing_ovirt_ssl.html)
I didn't know this doc so far, and am sorry if the doc on ovirt.org
(linked from it) is not enough. Patches/questions/issues are welcome!
I think it makes more sense to refine and perfect the "official"
documentation than to have each of us write his own blog post with a
"patch", unless it details specific/local issues that are not relevant
for a general document but would still be useful for other people.
and it works fine. The certificate is valid for a very long period.
(Good for maintenance minimization, not so good for security. But not
the scope of current email...)
It seems the vdsm certificate (/etc/pki/vdsm/certs/vdsmcert.pem), on hosts side, has been
renewed automatically at that time, but for only one year.
"at that time", meaning by following the official doc? Or the above
link? I didn't read it, but it does not mention "vdsm".
Perhaps it wasn't exactly at that time, but due to some other
update/action/whatever? You can try to correlate the cert start time
with your (engine+vdsm) logs.
Anyway, the hosts certs were indeed made shorter at some point, but
then back longer. So it greatly depends what exact version you used
while you touched them. See also this bug, and the linked patches:
https://bugzilla.redhat.com/show_bug.cgi?id=2079835
I think the previous point was:
https://bugzilla.redhat.com/show_bug.cgi?id=1824103
Meaning: Until 4.4.2 it was 1800 days, 4.4.3 to 4.5.0.6 it was 398
days, and since 4.5.0.7 it's 1827 days.
You should see a large part of the relevant history, even if I am not
sure all of it, but checking the git log of this file, searching for
"days". I usually search a somewhat-upper subdirectory, e.g.
"packaging" - good enough when searching locally with 'git log' (and
'less'), less convenient on a browser:
https://github.com/mz-pdm/ovirt-engine/commits/master/packaging/bin/pki-e...
Now we wonder, what will happen when the vdsm certificate will expire? hosts will stop
to be in the cluster?
Not sure, I think they'll become non-responsive.
Disclaimer: I am not an expert on engine<->vdsm comm.
if yes what should we do to avoid that?
The standard approach is to move each host to maintenance, then
"Enroll Cert" from the menu, then activate.
is there a possibility to also apply our custom cert as vdsm cert?
No.
This is for ovirt 4.4 running on rhel8
If 4.4 > 4.4.3, then indeed you got 398 days. But again, this isn't
part of the apache cert replacement procedure - more likely you did
'Enroll Cert', or reinstalled, or something like that.
Good luck,
--
Didi
1:05 p.m.
Hi David,
thx for your answer.
I have tried this non official documentation because it was the clearest and more straight
forward I've found.
indeed it's not perfect in terme of security, but having to renew each year so many
different certificate across multiple cluster is really not convenient. The first time we
had a certificate expiration we were not ready and long story short it brought us a
production issue...
indeed this doc doesn't mention vdsm, but the current start date of our vdsm
certificate is matching with the date where we applied this doc, so I was quite suprised
too, but it's definitively not related. Anyway we have a lot of vdsm cert that will
expire next year, and we should be ready. (ovirt 4.4.10)
I did a recent install of ovirt 4.5, and vdsm cert are valid for 5 years, which is really
better.
with our 4.4.10 clusters, if we "enrol cert", it will again be for one year? I
guess the only way to have a bigger period would be to update our cluster to 4.5?
thanks a lot, have a nice day
8:33 a.m.
On Fri, Dec 16, 2022 at 1:06 PM Vinz Vinz <vk(a)itiviti.com> wrote:
Hi David,
thx for your answer.
I have tried this non official documentation because it was the clearest and more
straight forward I've found.
indeed it's not perfect in terme of security, but having to renew each year so many
different certificate across multiple cluster is really not convenient. The first time we
had a certificate expiration we were not ready and long story short it brought us a
production issue...
indeed this doc doesn't mention vdsm, but the current start date of our vdsm
certificate is matching with the date where we applied this doc, so I was quite suprised
too, but it's definitively not related. Anyway we have a lot of vdsm cert that will
expire next year, and we should be ready. (ovirt 4.4.10)
I did a recent install of ovirt 4.5, and vdsm cert are valid for 5 years, which is really
better.
with our 4.4.10 clusters, if we "enrol cert", it will again be for one year? I
guess the only way to have a bigger period would be to update our cluster to 4.5?
I think you can also change the default cert lifetime with
engine-config, item VdsCertificateValidityInDays. Didn't test this
myself. If it works, it should affect new certificates, not existing
ones.
Best regards,
--
Didi
5:44 p.m.
Hi DAvid,
Do you see this parameter on your side? on my side I don't:
$engine-config -a | grep -i validity
Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false
WebSocketProxyTicketValiditySeconds: 120 version: general
CertificationValidityCheckTimeInHours: 24 version: general
ImageTransferClientTicketValidityInSeconds: 300 version: general
Thx
2:59 p.m.
On Mon, Dec 19, 2022 at 5:45 PM Vinz Vinz <vk(a)itiviti.com> wrote:
Hi DAvid,
Do you see this parameter on your side? on my side I don't:
$engine-config -a | grep -i validity
Picked up JAVA_TOOL_OPTIONS: -Dcom.redhat.fips=false
WebSocketProxyTicketValiditySeconds: 120 version: general
CertificationValidityCheckTimeInHours: 24 version: general
ImageTransferClientTicketValidityInSeconds: 300 version: general
I didn't test on a live system, only checked the source code. I now
see that it was exposed to engine-config only in 4.5.
It was added to the database before that, I think in 4.4.5 or so. See
if you have it in vdc_options, and if so, you can update it there,
using /usr/share/ovirt-engine/dbscripts/engine-psql.sh . Please search
the mailing list for examples about how to do that, thanks.
Best regards,
--
Didi
704
days inactive
709
days old
6 comments
2 participants
participants (2)
-
Vinz Vinz -
Yedidyah Bar David