Description of problem: - Unable to upload an image via Chrome 62.0.3202.89 and receives the following error. =---------------------------------------------- 017-10-26 18:08:06,709+08 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-3) [9a630175-ec10-4992-bb0a-1ded1e1757cd] EVENT_ID: UPLOAD_IMAGE_NETWORK_ERROR(1,038), Correlation ID: 9a630175-ec10-4992-bb0a-1ded1e1757cd, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Unable to upload image to disk c0ef3003-e5e5-492f-90b7-a67b344c3b14 due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https://<engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA =---------------------------------------------- - The self-signed SSL certificate added to the Trusted Root certification fails with the error when done via Chrome. - Works fine with Firefox browser Version-Release number of selected component (if applicable): ovirt-engine-4.1.6.2-0.1.el7.noarch Chrome 62.0.3202.89 Windows Client OS How reproducible: Steps to Reproduce: 1. Add the CA to the Trusted Root Certification to access engine from Chrome Browser 2. Check if the site is locked with SSL enabled. 3. If not, the SSL error is reported and form to accept the certificate is received. Actual results: - SSL enabled site with lock sign is seen. - Upload fails with errors. Expected results: - SSL works fine without reporting any errors. - Upload works. Additional info:
Daniel - is there anything we can do on our side?
(In reply to Allon Mureinik from comment #2) > Daniel - is there anything we can do on our side? According to Symantec support article [1], the issue is that "Google Chrome has deprecated the use of the Common Name field of an SSL certificate", which causes an issue with Symantec Web Security.cloud Service. @Dominik - can we remove the Common Name field from engine's certificate? [1] https://support.symantec.com/en_US/article.TECH240507.html
> can we remove the Common Name field from engine's certificate? From my understanding of the specifications, this should be possible. But there is the risk that we would run into trouble with clients still relying on the Common Name. Is there a reason to remove the Common Name?
(In reply to Dominik Holler from comment #5) > > can we remove the Common Name field from engine's certificate? > > From my understanding of the specifications, this should be possible. > But there is the risk that we would run into trouble with clients still > relying on the Common Name. > Is there a reason to remove the Common Name? The reason is that it's deprecated by Chrome and Symantec's service doesn't play nice with it. But if removing it is a risk, I guess we'll have to rely on the workaround.
Hello Daniel, The additional workarounds for the same are as follows which however didn't work well for me. https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors See also: https://www.chromium.org/administrators/linux-quick-start Apart from the workaround don't you think adding a fix would be suitable as we are likely going to encounter the same down the track for customers using Chrome browser. As mentioned take an alternative from the risk of removing the Common name. Ribu
(In reply to Ribu Tho from comment #7) > Hello Daniel, > > The additional workarounds for the same are as follows which however didn't > work well for me. > > https://www.chromium.org/administrators/policy-list- > 3#EnableCommonNameFallbackForLocalAnchors > > See also: > > https://www.chromium.org/administrators/linux-quick-start > > Apart from the workaround don't you think adding a fix would be suitable as > we are likely going to encounter the same down the track for customers using > Chrome browser. As mentioned take an alternative from the risk of removing > the Common name. > > > Ribu Unfortunately, if we can't remove the Common Name field from engine's certificate, I'm not sure what else we can do here from our side. @Dominik - do we have any other alternative perhaps?
I am not convinced that the existence of the Common Name is the reason for the issue. Ribu, what happens if you open https://engine:54323/images/ in chrome? If you are asked to accept the certificate and accept it, can you try to upload an image again?
Ribu, can you share the output in of Chome's developer tools console?
@Dominik, When accessing the link https://engine:54323/images/ on my lab machine for Chrome browser I receive the error below . I tried to access even after logging into the admin panel for this {"explanation": "This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.", "code": 401, "detail": "Not authorized", "title": "Unauthorized"} Additionally the customer has closed the case for which we have no developer tools console information available. Ribu
@Ribu, this error message can only be received if SSL is working correctly. Can you upload images with your lab machine?
@Ribu, I still do not understand the reason for the issue. Maybe in the customer's scenario, the ovirt-imageio's SSL certificate does not yet contain a Subject Alternative Name?