what happens at vdsm host certificate expiration

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

Hi, On Thu, Dec 15, 2022 at 3:29 PM Vinz Vinz <vk@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-enro...
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

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

On Fri, Dec 16, 2022 at 1:06 PM Vinz Vinz <vk@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

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

On Mon, Dec 19, 2022 at 5:45 PM Vinz Vinz <vk@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
participants (2)
-
Vinz Vinz
-
Yedidyah Bar David