Thread Info
  • State Verified Answer
  • +11 person also asked this people also asked this
  • Locked Locked
  • Replies 36 replies
  • Answers 4 answers
  • Subscribers 26 subscribers
  • Views 665324 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HTTPS scanning Web Protection SSL error ERR_CERT_COMMON_NAME_INVALID

KarstenStolten

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



This thread was automatically locked due to age.
Parents Reply Children
  • 0 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

  • 0 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.

  • 0 in reply to colly72

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

  • 0 in reply to sparkeh

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

  • 0 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?

  • 0 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.

     

     

     

     

  • 0 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?

  • 0 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

     

                                                                                                                         

    Regards,

    Aditya Patel
    Global Escalation Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.

  • 0 in reply to Aditya Patel

    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.

  • 0 in reply to Chris Hill

    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.

Unfiltered HTML