Description of problem: After installing websocket in a different host and trying to access the noVNC console, it fails in Google Chrome browser. The console doesn't fail in firefox. the engine certificate have been added the both browsers beforehand. Checking the logs is possible to see issues with ssl authentication: Accessing via firefox: ovirt-websocket-proxy[11146] INFO log_message:117 10.40.192.25 - - [09/Jul/2020 12:00:33] x.x.x.x - - [09/Jul/2020 12:00:33] Not a SSL connection, falling back to standard Websockify connection handling ovirt-websocket-proxy[11146] INFO log_message:117 x.x.x.x - - [09/Jul/2020 12:00:33] connecting to: b'y.y.y.y':b'5902' ovirt-websocket-proxy: INFO log_message:117 x.x.x.x - - [09/Jul/2020 12:00:33] connecting to: b'y.y.y.y':b'5902' Accessing via chrome: ovirt-websocket-proxy[11161] INFO msg:887 handler exception: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert certificate unknown (_ssl.c:897) Version-Release number of selected component (if applicable): 4.4.1 How reproducible: 100% Steps to Reproduce: 1. Install engine without websocket on engine A 2. Install websocket on engine B 3. Trusted the engine A certificate in the browser 4. Accessed a noVNC console in engine A Actual results: ssl error Expected results: no error Additional info: x.x.x.x and y.y.y.y are obfuscated ip addresses
Beni, do we have this covered in the tests? I want to rule out an environment issue
Also want to complement that when the websocket is running in the same host as the engine, it works on chrome (as well as firefox) Logs attached.
Did you set it up with engine-setup as described in: https://www.ovirt.org/develop/release-management/features/integration/websocketproxy-on-a-separate-host.html
Yes Arik
And does it work if you change 'wss' to 'ws' in ./usr/share/ovirt-engine/engine.ear/services.war/novnc-main.jsp ?
(might require to restart the engine)
I was able to reproduce this and it looks like Chrome is rejecting certificate from websocket proxy even if engine CA certificate is properly installed in the system.
Since v58 Chromium does not look at Common Name in certificates but compares host names only to the names in Subjet Alternative Names section. When engine-setup generates the certificate for websocket proxy it does not add the SAN section with hostname.
It's not specific to websocket-proxy, affects all separate machine pki (meaning, currently, also grafana). The bug is that we do not pass --san to the call to pki-enroll-request in engine:packaging/setup/ovirt_engine_setup/remote_engine.py
Verified on: ovirt-engine-4.4.3.8-0.1.el8ev.noarch ovirt-engine-websocket-proxy-4.4.3.8-0.1.el8ev.noarch Steps: 1. Install engine without websocket on engine A 2. Install websocket on engine B 3. Trusted the engine A certificate in the browser 4. Accessed a noVNC console in engine A UI via chrome Results: console successfully accessed on chrome
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.