HTTPS scanning Web Protection SSL error ERR_CERT_COMMON_NAME_INVALID

HI KarstenStolten, 

The new version of Chrome V58 will no longer accept certificates that do not have a subject alternate name.  Chrome is following RFC 2818 for this change.  Chrome V58 has now gone GA .

This could affect the Sophos Web appliance and Sophos UTM, which both use https scanning. The site generated certificate that we give back in these cases does not have a subject alternate name, meaning Chrome will reject the certificate and block the site

There are 3 options you may opt for. 

Option 1: Disable HTTPS scanning untill the issue is fixed. 

Option 2: Use another Web Browser . 

Option 3 *preferred: setting this GPO to ENABLED https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors 

Our Dev team are working on this issue should be resolved soon . 

Hello, I'm just wondering if there is any news on when we might see an update to resolve this issue?

As this is now starting to affect our organisation as well. We managed to stop the updates before our PCs were affected but a number of our Macs have already updated to Chrome 58 and can not get on Google websites and services.

Unfortunately Macs cannot use GPOs, so we have had to advise users to switch to Safari for the time being, but it would be better if Sophos could fix the issue with HTTPS certificate generation on their UTM system.

Thanks,

Dan Jackson (Lead ITServices Technician)

Long Road Sixth Form College

Cambridge, UK.

HI,

I've applied this and it has NOT fixed the issue unfortunately - exactly the same issue with HSTS enabled sites and Chrome 58 as before.

Disabling SSL inspection is not really a viable option, nor is rolling out a GPO.

Dan

Surely Sophos have had an idea that this was going to cause a problem?  Google have had this planned for months from what I can see, so how does a company as big as Sophos not patch their products in good time, to resolve any issue?  We shouldn't have to resort to changing group policy settings to implement a workaround.

colly72 said:

Surely Sophos have had an idea that this was going to cause a problem?  Google have had this planned for months from what I can see, so how does a company as big as Sophos not patch their products in good time, to resolve any issue?  We shouldn't have to resort to changing group policy settings to implement a workaround.

 

To be fair, you can find evidence of this hitting any major filtering provider you care to think of. Its not just Sophos being lazy ;)

Maybe it's a criticism of the industry as a whole then.  Still doesn't cover Sophos in much glory.

That's​ disappointing, and this still didn't work for you after re-generating the cert and deploying it again?

Actually - looks like doing that does make it work - certainly on a local test.

Probably stupid of me to not have thought of that, but I don't actually think it's mentioned anywhere as being needed.

Hi, under 9.413004 after regenerating the Signing CA certificate we find the issue is resolved for most websites; however we are still experiencing problems with some websites using 'wildcard' certificates, for example:

https://aaf1a18515da0e792f78-c27fdabe952dfc357fe25ebf5c8897ee.ssl.cf5.rackcdn.com/2066/blank-slate.style.css?v=1494272379000

The 'Subject Alternate Name' for the original certificate on this website is: *.ssl.cf5.rackcdn.com. This works fine when accessed with 'Decrypt and Scan' disabled.

However when accessed via our Sophos UTM, the Sophos certificate generated has a 'Subject Alternate Name' of 'a534b3cb973e1c6f094b-fd0bc916f1313f032c809744eb469080.ssl.cf5.rackcdn.com'

(Please note that this is *not* a wildcard certificate, and the hostname is different to the one through which the site is accessed.)

We get predictable SSL errors as a result. Please can others investigate so that I can report to Sophos?

Sorry for the delay , 

As you are aware of the issue with Chrome V58, the workaround is provided by enabling the fallback option.

Requires: Administrator CMD.

reg add HKLM\Software\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1

Hi Aditya,

No, I am reporting another problem when firmware 9.413004 is installed (which resolves the Chrome V58 issue).

I get the following error in Google Chrome when attempting to access the site above:

This server could not prove that it is aaf1a18515da0e792f78-c27fdabe952dfc357fe25ebf5c8897ee.ssl.cf5.rackcdn.com; its security certificate is from a534b3cb973e1c6f094b-fd0bc916f1313f032c809744eb469080.ssl.cf5.rackcdn.com. This may be caused by a misconfiguration or an attacker intercepting your connection.

Running reg add HKLM\Software\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1 as Administrator does not resolve this issue.

If you attempt to visit the following site under 9.413004 with Decrypt and Scan enabled and EnableCommonNameFallbackForLocalAnchors enabled you should get the same error:

https://aaf1a18515da0e792f78-c27fdabe952dfc357fe25ebf5c8897ee.ssl.cf5.rackcdn.com/2066/blank-slate.style.css?v=1494272379000

Only workaround I can find at present is to disable Decrypt and Scan.

It is entirely possible they are pinning the certificate, which will cause the SSL decryption to fail.  That is what the error sounds like to me.  That being said, it is not failing for me.  I can hit the site, and it is reporting the certificate itself, not the cert for my UTM.  That is with decrypt and scan enabled.

It is entirely possible they are pinning the certificate, which will cause the SSL decryption to fail.  That is what the error sounds like to me.  That being said, it is not failing for me.  I can hit the site, and it is reporting the certificate itself, not the cert for my UTM.  That is with decrypt and scan enabled.

Hi Darrelr,

If you're getting the certificate itself, and not the cert from your UTM, you're not decrypting and scanning that site - do you have 'Decrypt and scan the following categories' enabled?

Agreed - but probably not for the same reason you are thinking.  I had it set to decrypt and scan all sites.  I am familiar with HTTPS scanning on the UTM.  Nearly all of the sites I hit delivered the UTM certificate to Chrome.  This one that you posted did not.  I checked the logs, and there were no exceptions set on the site at all.  I am merely pointing out that just because you tell the UTM to decrypt and scan everything, it does not mean that it does.  Pinned certificates can prevent the scanning by the UTM and will typically fail the communication as well because of a certificate mismatch between what it knows it should see and what it does see.

Google ships Chrome with some certs built in, and will always use them.  Whether this symantec cert is or is not included, I don't know.