[ovirt-devel] Re: Certificate checking on TLS migrations to an IP address

Daniel P. Berrangé <berrange(a)redhat.com&gt; writes: > On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote: >> Daniel P. Berrangé <berrange(a)redhat.com&gt; writes: >> > >> > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: >> >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem >> >> with certificate checking. >> > >> >> >> >> oVirt uses the destination host IP address, rather than the host name, >> >> in the migration URI passed to virDomainMigrateToURI3. One reason for >> >> doing that is that a separate migration network may be used for >> >> migrations, while the host name resolves to the management network >> >> interface. >> >> >> >> But it causes a problem with certificate checking. The destination IP >> >> address is checked against the name, which is a host name, given in the >> >> destination certificate. That means there is mismatch and the migration >> >> fails. I don't think it'd be a very good idea to avoid the problem by >> >> putting IP addresses into server certificates. >> > >> > In fact that is *exactly* what you should be doing. >> > >> > Traditionally certificates were created with the 'common name' field >> > holding the fully qualified DNS based hostname for the server. >> > >> > This was long known to be a problem because it is very common for >> > servers to have multiple DNS names, or for clients to use the >> > unqualified hostname, or use the IP address(es). >> >> The problem with putting IP addresses into certificates is that the >> certificate must be updated each time an IP address changes, is added or >> is removed. Doing this in oVirt would be complicated and error-prone. >> While host names are stable, host networks and the related IP addresses >> may change. >> >> > Thus, the "Subject alt name" extension was created. This allows >> > certificates to be created containing multiple hostnames and >> > multiple IP addresses. The certificate will be validated correctly >> > if any one of those data items matches. When 'subject alt name' is >> > present in a certificate, the 'common name' field should be completely >> > ignored by compliant TLS clients, so you are free to put whatever >> > you want in the common name - hostname or IP address or blah... >> >> We can switch to using Subject Alt Name and we have a patch for that now >> based on your advice, but it doesn't solve the problem with tracking IP >> address changes and updating the corresponding certificates whenever a >> change occurs. >> >> > If you look at our docs, we updated them to illustrate how to >> > issue certs containing hostnames + IP addresses: >> > >> > https://libvirt.org/remote.html#Remote_TLS_server_certificates >> > >> >> >> >> Is there any way to make TLS migrations working under these >> >> circumstances? For instance, SPICE remote-viewer allows the client to >> >> specify the certificate subject to expect on the host when connecting to >> >> it using an IP address. Can (or could) libvirt do something similar? >> >> Would it be possible? We have host names in the certificates under our >> control and we know which host name to expect in the certificate >> regardless the IP address used for the given connection. Checking the >> certificate against a given host name would solve the problem easily and >> robustly for us. > > There's two options that could make it work > > - Define a new migration parameter which lets apps pass in the hostname > to use for TLS cert validation to libvirt, which would have to then > pass it into QEMU I think this is the best option. We know the destination host name, while we need to use an IP address to connect to it in order to use a particular network.