On Mon, Sep 23, 2019 at 03:04:46PM +0200, Milan Zamazal wrote: > Milan Zamazal <mzamazal@xxxxxxxxxx> writes: > > > Daniel P. Berrangé <berrange@xxxxxxxxxx> writes: > > > >> On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote: > >>> 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. > >>> > > >>> > 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. > > If we can agree on this, should I file a corresponding RFE on libvirt? Yes, please go ahead & do that Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
