On Sun, Dec 6, 2020 at 8:14 PM Derek Atkins <[email protected]> wrote: > > Hi again, > > I also noticed that ca.pem was not updated -- it's still using Sha1.
You are right - we didn't make engine-setup recreate existing certs for this - "Renew" deals with other stuff [1]. We only change the default for new ones [2], and wrote a procedure [3][4] for doing this manually. At the time, this wasn't mandatory - browsers didn't reject sha1. Perhaps now it should be. [1] https://www.ovirt.org/develop/release-management/features/infra/pki-renew.html [2] https://gerrit.ovirt.org/c/ovirt-engine/+/65927 (I see that I even didn't open a bug for this at the time, not sure why) [3] https://www.ovirt.org/documentation/upgrade_guide/#Replacing_SHA-1_Certificates_with_SHA-256_Certificates_4-2_local_db [4] https://bugzilla.redhat.com/show_bug.cgi?id=1420577 (This is a RHV doc bug, and the result was an update to RHV docs, which eventually were also published as [3] above) > I don't know if this will be an issue with remote-viewer if I wind up > refreshing the host cert? As I said, at the time it didn't seem to be mandatory, and docs seemed to be enough. If you feel otherwise, please open a bug. I think there is a difference, or at least there was, between what browsers did/do with https certs, and what they did with CA certs. If you had a CA cert already accepted/imported/trusted by the browser, and then you entered a site with a cert signed by this CA, but with a SHA1 signature, this was one separate case. Browsers started warning/ rejecting them earlier. If you have a CA cert with a SHA1 signature, and want to import that to a browser, that's another case. I didn't test recently (or much over time, other than working on these bugs) with recent browsers, but I think it took longer until they rejected (if indeed they do - not sure all of them do). Best regards, > > -derek > > On Sun, December 6, 2020 7:44 am, Yedidyah Bar David wrote: > > On Sun, Dec 6, 2020 at 12:34 AM Derek Atkins <[email protected]> wrote: > >> > >> Hi, > >> > >> I've got a single-host hosted-engine deployment that I originally > >> installed with 4.0 and have upgraded over the years to 4.3.10. I and > >> some > >> of my users have upgraded remote-viewer and now I get an error when I > >> try > >> to view the console of my VMs: > >> > >> (remote-viewer:8252): Spice-WARNING **: 11:30:41.806: > >> ../subprojects/spice-common/common/ssl_verify.c:477:openssl_verify: > >> Error > >> in server certificate verification: CA signature digest algorithm too > >> weak > >> (num=68:depth0:/O=<My Org Name>/CN=<Host's Name>) > >> > >> I am 99.99% sure this is because the old certs use SHA1. > >> > >> I reran engine-setup on the engine and it asked me if I wanted to renew > >> the PKI, and I answered yes. This replaced many[1] of the certificates > >> in > >> /etc/pki/ovirt-engine/certs on the engine, but it did not update the > >> Host's certificate. > > > > Indeed. > > > >> > >> All the documentation I've seen says that to refresh this certificate I > >> need to put the host into maintenance mode and then re-enroll.. However > >> I > >> cannot do that, because this is a single-host system so I cannot put the > >> host in local mode -- there is no place to migrate the VMs (let alone > >> the > >> Engine VM). > >> > >> So.... Is there a command-line way to re-enroll manually and update the > >> host certs? > > > > I don't think you'll find anything like this. > > > > People did come up in the past with various procedure to hack pki like > > what > > you want, but these are, generally speaking, quite fragile - usually do > > not > > get updated over versions etc. > > > > I am pretty certain the only way to do this using "official" tools/docs > > is: > > > > 1. Stop all VMs except for the engine one. > > > > 2. Take a backup with engine-backup. > > > > 3. Stop the engine VM. > > > > 4. Reinstall the host OS from scratch or use ovirt-hosted-engine-cleanup. > > > > 5. Provision the host again as a hosted-engine host, using > > '--restore-from-file'. > > Either using new storage for the engine, or after cleaning up the existing > > hosted-engine storage. > > > > If you still want to try doing this manually, then the tool to use is > > pki-enroll-request.sh. IIRC it's documented. You should find what > > keys/certs > > you want to replace, generate new keys and CSRs (or use existing keys and > > generate CSRs, or even use existing CSRs if you find them), copy to the > > engine, > > sign with pki-enroll-request.sh, then copy the generated cert to the host. > > I am > > almost certain there is no way to tell vdsm (and other processes) to > > reload > > the certs, so you'll have to restart it (them) - and this usually > > requires putting > > the host in maintenance (and therefore stop (migrate) all VMs). > > > >> Or some other way to get all the leftover certs renewed? > > > > Which ones, specifically? > > > >> > >> Thanks, > >> > >> -derek > >> > >> [1] Not only did it not update the Host's cert, it did not update any of > >> the vmconsole-proxy certs, nor the certs in /etc/pki/ovirt-vmconsole/, > >> and > >> obviously nothing in /etc/pki/ on the host itself. > > > > AFAIR no process uses these certs as such. There are only processes that > > use > > the ssh-format keys extracted from them, which do not include a signature > > (sha1 or whatever). > > > > If you think I am wrong, and/or notice other certs that need to be > > regenerated, > > that's a bug - please open one. Thanks! > > > > Re remote-viewer/spice: You didn't say if you tried again after > > engine-setup > > and what happened. In any case, this is unrelated to vmconsole (which is > > for > > serial consoles, using ssh). But you might still need to regenerate the > > host > > cert. > > > > BTW: You can try using novnc and websocket-proxy - engine-setup does > > update > > the cert for the latter, so this might work as-is. > > > > Best regards, > > -- > > Didi > > > > > > > -- > Derek Atkins 617-623-3745 > [email protected] www.ihtfp.com > Computer and Internet Security Consultant > -- Didi _______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/GJUXMQUVPYTOGRQMCYPV6V2FZDTOV62W/
