Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518059 - Cannot upload image via Chrome 62
Summary: Cannot upload image via Chrome 62
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-imageio-proxy
Version: 4.1.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.2.1
: ---
Assignee: Daniel Erez
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-28 04:48 UTC by Ribu Tho
Modified: 2019-03-12 09:19 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 13:54:07 UTC
oVirt Team: Storage


Attachments (Terms of Use)

Description Ribu Tho 2017-11-28 04:48:02 UTC
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:

Comment 2 Allon Mureinik 2017-11-28 07:52:12 UTC
Daniel - is there anything we can do on our side?

Comment 4 Daniel Erez 2017-11-29 13:13:01 UTC
(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

Comment 5 Dominik Holler 2017-11-29 16:15:53 UTC
> 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?

Comment 6 Daniel Erez 2017-11-29 16:21:21 UTC
(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.

Comment 7 Ribu Tho 2017-11-29 21:48:31 UTC
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

Comment 8 Daniel Erez 2017-11-30 06:13:53 UTC
(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?

Comment 9 Dominik Holler 2017-11-30 09:23:08 UTC
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?

Comment 10 Dominik Holler 2017-11-30 09:28:31 UTC
Ribu, can you share the output in of Chome's developer tools console?

Comment 11 Ribu Tho 2017-12-01 00:30:01 UTC

@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

Comment 12 Dominik Holler 2017-12-01 07:29:09 UTC
@Ribu,
this error message can only be received if SSL is working correctly.
Can you upload images with your lab machine?

Comment 16 Dominik Holler 2017-12-06 07:21:11 UTC
@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?


Note You need to log in before you can comment on or make changes to this bug.