Daniel P. Berrangé <berrange@xxxxxxxxxx> 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. OK, thank you for explanation and the doc reference. Regards, Milan > 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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
