[libvirt-users] 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
On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote:
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.
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 - The source host libvirtd has a connection to the dest host libvirtd. It can thus ask dest host what its primary hostname is, and then automatically tell QEMu to use that for TLS cert validation. This could cause problems though for people already using TLS certs with IP addresses in. 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 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote:
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.
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.
- The source host libvirtd has a connection to the dest host libvirtd. It can thus ask dest host what its primary hostname is, and then automatically tell QEMu to use that for TLS cert validation. This could cause problems though for people already using TLS certs with IP addresses in.
This doesn't look very good from the security point of view, since then the source doesn't check it really connects to the host it expects, just that the destination host has a valid certificate signed by the right CA (I suppose). It may be good enough or even useful for some scenarios, but not for others. Thanks, Milan
Milan Zamazal <mzamazal@redhat.com> writes:
Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote:
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.
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? Thanks, Milan
- The source host libvirtd has a connection to the dest host libvirtd. It can thus ask dest host what its primary hostname is, and then automatically tell QEMu to use that for TLS cert validation. This could cause problems though for people already using TLS certs with IP addresses in.
This doesn't look very good from the security point of view, since then the source doesn't check it really connects to the host it expects, just that the destination host has a valid certificate signed by the right CA (I suppose). It may be good enough or even useful for some scenarios, but not for others.
On Mon, Sep 23, 2019 at 03:04:46PM +0200, Milan Zamazal wrote:
Milan Zamazal <mzamazal@redhat.com> writes:
Daniel P. Berrangé <berrange@redhat.com> writes:
On Wed, Sep 18, 2019 at 12:18:32PM +0200, Milan Zamazal wrote:
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.
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 :|
participants (2)
-
Daniel P. Berrangé -
Milan Zamazal