Re: [libvirt-users] Certificate checking on TLS migrations to an IP address

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). 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... 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? > Or is there any other mechanism to handle this problem? Regards, Daniel