8:20 a.m.
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(a)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-c...
-- 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(a)ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant