Most of them are outdated , but provide historical design context.
They are not user documentation and should not be treated as such.
Documentation is available here.
One certificate-key pair per NIC
This feature is necessary to get TLS right on hosts. Once implemented, it will erradicate need for explicit host subject override as used for spice now and it will also allow separation of migration network from management network.
- Name: djasa (Djasa)
- Email: email@example.com
- Won't be able to implement myself. Feel free to take this
- Not started
- Last updated date: Mon June 25 2012
Currently, VDSM takes "one TLS certificate rules them all" approach to TLS-enabled services on host. This is sufficient as long as all services are accessed via management network FQDN/IP.
Things go wrong when the host is multihomed with separation of various kinds of traffic because standards-based SSL/TLS handshakes fail because clients will connect to secondary adresses (like that of display networks) but the services will present themselves with management network address (IP or FQDN) in the CN entry of Subject field of their certificate. This produces infamous ssl error:
that will prevent to establish a connection. Spice consoles fired by admin/user portal work this around by passing the technically incorrect host subject used by spice-server to the client via Portal and browser plugin which will then override default subject check. Other stuff like migration is not handled at all.
This seems to be the correct path to get the issue straight:
- server certs/keys used on host should be generated by vdsm itself if it isn't already so
- use separate files for every service that uses certificates (similarly as libvirt/qemu is pointed for spice certs to
/etc/pki/vdsm/libvirt-spice) or learn to point the services to correct certs – if not already present
- certs/keys should be regenerated after saving of a new NIC configuration that affected address and signed again by oVirt engine CA
- provision for definition of secondary NICs by their FQDN should be made so that CN=FQDN scenario is handled as well when implemented by engine
- after new keys are ready, cert and key files used by affected services should be replaced by new ones (contents of
/etc/pki/vdsm/libvirt-spicewhen the display network is modified for instance).
Note: I'm not familiar with oVirt at code level so the closer to it, the bigger grain of salt has to be taken.
Benefit to oVirt
- get rid of Host Subject hack for Display Network
- allow using correct TLS certificates
- allow separation of migration network from management network
- maybe other network roles can be made separate as well
- when done right, DNS/IP modifications of host without host reinstall could be based on this feature
Dependencies / Related Features
- if TLS keys/certificates workflow from the one below, it should be modified accordingly (probably as a separate feature?):
- NIC configuration changes
- vdsm generates a new key and a certificate request
- vdsm passes a cert request to be signed by engine's CA
- engine's CA:
- signs the request hands the resulting certificate
- hands the new certificate back to host
- puts an old certificate on CRL (if any) as it is no longer valid
- vdsm puts the new certificate in place and updates all the configuration and/or symlinks that use it
- Regenerate Spice certificate on Host name/IP change
- Backend: changing host name does not change the spice certificate on the vds -> can't connect through trusted spice
- private, subject says it all, resolved by forcing host remove & re-add instead of host name/IP change since 3.0
- Return hypervisor FQDN to spice client instead of hypervisor IP address
- request to define secondary interface that has Display Network role by its FQDN instead of IP address
- concept can be extrapolated to define any interface used for any role by FQDN, not just management one
- in addition to IPv4/DNAT use case, this will help oVirt get ready for bunch of other scenarios:
- IPv4/IPv6 dual-stack networking
- multiple IPv6 addresses on the interface at the same time
- IPv6 Network Prefix Translation compatibility
- as said above - material for its own feature page?
- expose host subject in host properties or VM properties
- request to get host-subject-override hack to REST API as well
Documentation / External references
Generate separate certificates for spice / display network, update them on display network modification
- this very page is directly based on the RFE