Authors:

avatar of David Jaša

David Jaša

Feature pages are design documents that developers have created while collaborating on oVirt.

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

Summary

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.

Owner

  • Name: djasa (Djasa)
  • Email: djasa@redhat.com
  • Won’t be able to implement myself. Feel free to take this

Current status

  • Not started
  • Last updated date: Mon June 25 2012

Detailed Description

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:

SSL_connect: error:00000001:lib(0):func(0):reason(1)

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.

Proposal

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-spice when 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?):
    1. NIC configuration changes
    2. vdsm generates a new key and a certificate request
    3. vdsm passes a cert request to be signed by engine’s CA
    4. engine’s CA:
      1. signs the request hands the resulting certificate
      2. hands the new certificate back to host
      3. puts an old certificate on CRL (if any) as it is no longer valid
    5. vdsm puts the new certificate in place and updates all the configuration and/or symlinks that use it

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