Bug 1518059

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?