libvirt users - Sep 2019 - Re: Certificate checking on TLS migrations to an IP address

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.

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?

Thanks,
Milan

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
-- 
|: 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 :|

Daniel P. Berrangé <berrange@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

Daniel P. Berrangé <berrange@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.
>
> 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.
>> Or is there any other mechanism to handle this problem?
Thanks,
Milan