HTTPS scanning Web Protection SSL error ERR_CERT_COMMON_NAME_INVALID

Hi

After Google has updated Chrome, we now have problems accessing websites with SSL.

HTTPS Scanning is enabled on the Sophos UTM and the problem seems to be that Chrome no longer accepts an empty DNS name in the SSL certificate presented in the browser.

Does anyone have a solution to this?

I guess that the best solution would be for Sophos to change the way they generate the "Man in the middle" certificate so that the website URL is listed in the DNS (or SAN) in the certificate.

Anyone?

Kind regards

Karsten Stolten

  • In reply to Aditya Patel:

    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

  • In reply to D B:

    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.

  • In reply to colly72:

    colly72

    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 ;)

  • In reply to sparkeh:

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

  • In reply to D B:

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

  • In reply to iTechThingsSeriously:

    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.

     

     

     

     

  • In reply to Aditya Patel:

    Hi,

    I wanted to know if the problem has been resolved ? I am using the Web Application and am experiencing the same error on my clients

    I have disabled https scanning on the appliance but don't want to keep it like that.. Will there be an update for the Web Appliance as well?

    Peter 

  • In reply to Peter Levy:

    For UTM the issue is resolved with version 9.413004.

    So for Web Appliance I think it will be resolved too, but you should ask Sophos Support directly or maybe try the web appliance forum.

    Best

    Alex

  • In reply to Peter Levy:

    Hey,

    Sophos Web Appliance Version 4.3.1.4 is supposed to fix this issue, according to the Version 4.3.1.4 Release Notes. I've seen it being rolled out beginning on 25.04.

    Best Regards
    Markus

  • In reply to Aditya Patel:

    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?

  • In reply to Chris Hill:

    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