Hi Didi, Sorry for the multiple emails yesterday. I'm going to respond to all of your responses in this one. On Mon, December 7, 2020 3:31 am, Yedidyah Bar David wrote:
On Sun, Dec 6, 2020 at 8:14 PM Derek Atkins <derek@ihtfp.com> 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.
I should point out that it's not the browsers that are rejecting SHA1, but it is remote-viewer that is. My Fedora-33 firefox connected to my Sha1-using Ovirt HTTPS just fine, without any complaints. Granted, as I note later, these certs were already imported and accepted in firefox years ago, so that could be why there was not complaints. However, the console.vv file sent to remote-viewer includes the CA cert -- but I'm not sure if it's complaining about that or the host cert that gets sent during the connection; I can't tell from the output. I know it's the CA cert that's sent in the .vv file, but I'm not 100% sure which particular source is being used, and I'm not sure which cert is considered "bad" by the viewer. [snip]
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 already refreshed the CA cert, so unfortunately I wont be able to test this for sure. I know that refreshing the CA cert on the engine alone is not sufficient -- the console.vv file still has the old one, even after an engine restart.
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.
Probably true, but firefox was not complaining with the Sha1 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.
I think I had already accepted the site cert which is probably why it wasn't complaining about it being SHA1.
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).
Indeed. I already had both the SHA1 CA cert and the SHA1 host cert accepted in my Firefox trust before I upgraded, so perhaps that's why I didn't see any issues in F33. I removed both and re-imported the (new) CA cert.
One more question:
Can you verify that etc/pki/libvirt/clientcert.pem, etc/pki/vdsm/certs/vdsmcert.pem, and etc/pki/vdsm/libvirt-spice/server-cert.pem are all supposed to be same certificate (on the host)? By a quick find | grep all three of these files appear to be the <Host>.cer certificate file?
Yes, and also vdsm/libvirt-vnc/server-cert.pem .
I don't see this directly in /etc/pki on the host? All I see is: # ls -l /etc/pki/vdsm/ total 8 drwxr-xr-x. 2 vdsm kvm 4096 Dec 6 17:16 certs drwxr-xr-x. 2 vdsm kvm 80 Jun 7 2020 keys drwxr-xr-x. 2 vdsm kvm 4096 Dec 6 17:18 libvirt-spice And /etc/pki/vdsm does not exist on the engine. Indeed: # find /etc/pki -name server-cert.pem /etc/pki/vdsm/libvirt-spice/server-cert.pem
Does it matter that ca.der didn't change? I don't know if that is a self-signed cert that might be problematic?
ca.der is not used by anything, you can ignore it. The private key of the CA is in /etc/pki/ovirt-engine/private/ca.pem, and the public key is in /etc/pki/ovirt-engine/ca.pem. That's what all tools use.
Actually, I verified that ca.der *IS* used -- that's what gets sent out if you access http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA -- so I had to update that in order to make the new cert available.
Generally speaking, the project considers the "standard" use case to be a setup of at least two hosts, and at least one host "extra" (in terms of capacity), so that if a host fails, you can still keep everything up. In that regard, a single-host setup is considered a kind of "corner case", meant mainly for testing/development, not production. Is there such a big advantage in using oVirt for a single host, compared to virt-manager?
The main advantages of ovirt over virt-manager is the access-control and remote-access capabilities. Specifically, I have several users which have different access to different VMs and their consoles. Without providing ssh access to the host, I wasn't sure how to provide that access in a clean way via virt-manager. I *used* to use vmware-server, and kept that running as long as I could (on a single server). But that hardware was running long in the tooth, so I migrated to ovirt because it gave me a similar web-based UI interface to my users so it was relatively easy to migrate them. When I migrated 4-5 years ago, virt-manager was still in relative infancy and, IIRC, didn't have much remote capability. Of course, because of this view that ovirt "requires" multiple hosts, there are several upgrade issues here. I don't mind having to reboot the host periodically (like once or twice a year); I can schedule that kind of downtime. But it would cost about $10-12k to add two more hosts and the 10Gb infrastructure necessary to have a true 3-host ovirt deployment, and my users don't want to spend that (and I cannot afford that on my own). When I asked them, the response was "we can live with periodic downtime; it's not worth $10k to gain one more nine"). I should add that this deployment is 30% personal, 5% for friends, and 65% for various open-source projects on a volunteer basis, so there is not a funding source for the resources. I donate my time, my electricity, and my network to run and maintain it. There's still multiple single points of failure -- I had a 53-hour power outage after Hurricane (well, tropical storm by the time it hit us) Eta came through, and I've had several network outages, some due to local fiber cuts and one due to an upstream router failure. So even if I had 2 more ovirt hosts, it wouldn't solve THOSE issues, which frankly hit much more often than me having to reboot! I still love this project. I think ovirt is the best (OSS) VM management solution out there. But I wish there was more support for smaller production deployments like mine, and that the development team considered single-host production deployments in their plans and testing. Again, thank you for all your support. I have a scheduled reboot tonight so I'll let you know how it goes after I restart. -derek PS: Happy (almost) Hannukah! -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant