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

Milan Zamazal mzamazal at redhat.com
Wed Sep 4 14:01:53 UTC 2019


Daniel P. Berrangé <berrange at redhat.com> 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




More information about the libvirt-users mailing list