Description of problem: Generate separate certificates for spice / display network. The problem with current practice of use of vdsm certificates also for spice is that when separate display network is used, host subject mismatch of what spice-server says about itself (in CN=<management_network_address>) and where client connects is produced. This is "traditionally" worked around by passing a host subject via engine, portals and browser plugin to the client which validates host-subject passed by spice-server against this value but: 1) it is and ugly hack that goes against the nature of TLS/PKI 2) it isn't supported in API (see bug #807384) Version-Release number of selected component (if applicable): vdsm-4.9.6-16.0 How reproducible: always Steps to Reproduce: 1. set up host so that its management interface is host-mgmt.example.com 2. set up display network on the host to host-display.example.com 3. activate the host (possibly reinstall from admin portal), start the VM 4. get the subject of server certificate the VM uses Actual results: subject contains CN=host-mgmt.example.com Expected results: subject contains CN=host-display.example.com Additional info:
oVirt feature page based on this RFE: https://bugzilla.redhat.com/show_bug.cgi?id=835018
(In reply to comment #1) > oVirt feature page based on this RFE: > https://bugzilla.redhat.com/show_bug.cgi?id=835018 Wrong link? Also, put it in the URL section of the BZ.
(In reply to comment #2) > (In reply to comment #1) > > Wrong link? Also, put it in the URL section of the BZ. Yes. Correct link (added to URL too): http://www.ovirt.org/wiki/Features/One_certificate-key_pair_per_NIC
michal - thoughts on this?
I don't think it can go away. IIUC when connecting through NAT we do not differentiate interfaces, for vdsm it is the same connection as if from internal nw. It may make sense for display nw specificaly, but I'm not sure it's worth the effort when it's already working as it is and we would anyway need it for NAT - e.g. with the new Display Address Override David?
It would be cleaner for host subject CN to match display network name/address (or display network override name/address) but since the host subject is correctly reported in the API, the status quo is not that bad. Itamar/Michal, please deprecate the feature page accordingly.