Description of problem: Post issue after BZ1116036, final websocket certs file path is hardcoded, does not respect fqdn of the machine. # grep -IR WEBSOCKET_PROXY_CERT_NAME /usr/share/ovirt-engine/ /usr/share/ovirt-engine/setup/plugins/ovirt-engine-setup/websocket_proxy/pki.py: name=owspcons.Const.WEBSOCKET_PROXY_CERT_NAME, /usr/share/ovirt-engine/setup/ovirt_engine_setup/websocket_proxy/constants.py: WEBSOCKET_PROXY_CERT_NAME = 'websocket-proxy' /usr/share/ovirt-engine/setup/ovirt_engine_setup/websocket_proxy/constants.py: '%s.key.nopass' % Const.WEBSOCKET_PROXY_CERT_NAME, /usr/share/ovirt-engine/setup/ovirt_engine_setup/websocket_proxy/constants.py: '%s.cer' % Const.WEBSOCKET_PROXY_CERT_NAME, /usr/share/ovirt-engine/setup/ovirt_engine_setup/websocket_proxy/constants.py: '%s.req' % Const.WEBSOCKET_PROXY_CERT_NAME, [root@jb-onqa ~]# find /etc/pki/ovirt-engine/certs/ /etc/pki/ovirt-engine/certs/ /etc/pki/ovirt-engine/certs/websocket-proxy.cer /etc/pki/ovirt-engine/certs/engine.cer [root@jb-onqa ~]# cat /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf PROXY_PORT=6100 SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/websocket-proxy.cer SSL_KEY=/etc/pki/ovirt-engine/keys/websocket-proxy.key.nopass FORCE_DATA_VERIFICATION=True CERT_FOR_DATA_VERIFICATION=/etc/pki/ovirt-engine/certs/engine.cer SSL_ONLY=True [root@jb-onqa ~]# grep /etc/pki/ /tmp/out open("/etc/pki/ovirt-engine/certs/engine.cer", O_RDONLY) = 4 stat("/etc/pki/ovirt-engine/certs/websocket-proxy.cer", {st_mode=S_IFREG|0600, st_size=5285, ...}) = 0 Version-Release number of selected component (if applicable): ovirt 3.5 beta2 How reproducible: 100% Steps to Reproduce: 1. yum install ovirt-engine-websocket-proxy 2. engine-config # try to survive the setup :) 3. check where final cert is saved on websocket proxy host Actual results: /etc/pki/ovirt-engine/certs/websocket-proxy.cer Expected results: /etc/pki/ovirt-engine/certs/websocket-proxy-${fqdn}.cer or something like this, see BZ1116036 Additional info:
We renamed the cert on the engine host just to highlight that the cert is relative to another host. an host witch just serve the websocket proxy instead just need its own wsp cert and it knows its hostname. A variation in the cert naming schema than will also require a modification in the daemon configuration.