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

Sophos XG breaks SSL when connecting to Outlook Anywhere

Hi, I have setup a virtual XG firewall at home. I have have created an "allow all" policy for the web filter and have switched off the "Scan HTTPS" Feature. In my web browsers, this works fine and I see the SSL certificates of all the websites I visit.

When I start Outlook and connect to the mailbox of my company, I get a certificate warning from Outlook 2013 that shows the Sophos CA. Obviously, the XG appliance is breaking SSL for the connection to Outlook Anywhere. The company is running Exchange Server 2013.

When I connect to another Exchange 2013 system, the certificate warning does not appear, which totally confuses me. I assume this issue might be related to Exchange 2013 autodiscover, but I am sure it is related to Sophos XG as well. I did not have this problem with UTM 9 that I have been using before migrating to XG.

Do you have any ideas on how to resolve this issue?

Kind regards, Matthias



This thread was automatically locked due to age.
Parents
  • If Outlook complains about the certificate it means that connection to the company's Outlook is made using a rule with HTTPS scanning enabled.

    Haven't you created "Outlook Business Rule" and have forgotten about it ? Use LogViewer for WebFilter to find which HTTP request go to specific rules.

  • OK, I got a step further now. In my "ANY/ANY/PERMIT"-rule I had the web filter policy "allow all" activated. If I set this to "none", the certificate warning does not occur. But I do not see any options to modify this web filter policy. Strange behaviour...

    Kind regards, Matthias

  • Matthias,

    check on your policy rule if "Decrypt and Scan HTTPS" is enabled. Use log viewer to see which rule is applied.

    Luk

  • Yes, this is and has always been disabled. In the web browser I can open webmail and it comes with the original CA, but using Outlook, SSL will be broken. It might be a combination of not 100% perfect Autodiscover configuration on the one hand and the processing in XG on the other hand.

    As I mentioned, I can reproduce the behaviour with only one Exchange Server 2013. When connecting to another one (both outside my organization), everything seems to be fine.

    Regards, Matthias

Reply
  • Yes, this is and has always been disabled. In the web browser I can open webmail and it comes with the original CA, but using Outlook, SSL will be broken. It might be a combination of not 100% perfect Autodiscover configuration on the one hand and the processing in XG on the other hand.

    As I mentioned, I can reproduce the behaviour with only one Exchange Server 2013. When connecting to another one (both outside my organization), everything seems to be fine.

    Regards, Matthias

Children
  • Good evening,

    with the help of a debugging proxy I found the reason for the certificate warning in Outlook and I think it is a bug of XG´s web filtering module.

    Let us assume the connection to Outlook Anywhere goes via mail.company.com. During autodiscover, Outlook automatically tries to establish a connection to the main domain company.com. However, company.com exists in DNS, but the server does not accept HTTPS connections. If I open that URL without XG web filtering in my browser, I get a "page cannot be displayed" error. After activating web filtering (without HTTPS scanning, of course), I get a certificate warning. If I ignore this and continue, I get a blank page. The CA of the certificate shown is from my Sophos XG.

    This is also the solution for the question why I could connect to another Exchange 2013 system without certificate warning. For this server, the URL https://company.com is available and thus there is no interference with the Sophos CA.

    Kind regards, Matthias

  • has anyone found a permanent fix for this?  we are using Office 365 with outlook client and autodiscovery.  I am also getting the certificate warning. 

    On our default outbound policy, we have not turned on HTTP or HTTPS malware scanning.  I have tried turning it on with an exception created for the office 365 domain, but I get the same result.

  • The only way to currently fix this is to deploy the SSL Certificate from the XG found under Protection > Web Server Protection > Certificate Authority and downloading it to the devices or deploying by Group Policy.

    The not advised way is to physically turn off web filtering.

    Neither are appropriate really (except in the first instance and you're proxying) and this does need to be fixed.

  • Kind of a noob here. Which one do i download?

  • Hi Ben,


    This is the certificate you want to download and install as a trusted root certificate on your computers:

    Hope that helps,

    Emile

  • Emile,

    I cannot agree with you that installing the Sophos SSL CA is a solution and it is the only solution.  This is not acceptable.

    I have different vendors visit my office all the time.  A lot of them use Office 365 emails.  How am I going to accommodate these visitors?  This is very embarrassing when I had to explain the issue to each of them.  These vendors might find my work unprofessional or suspect our firewall is lacking protection.

    More importantly.  How do I know if this SSL certificate issue will not break other things?

    I currently have to set the Web filter to None in order to avoid warning messages on my office staff's Outlook.  This work around is no good.

    I agree with Matthias that there is a bug within the XG's web filtering module.

    Ben

  • We are investigating what is probably a related case.  AFAIK the issue is something like:
    Outlook tries several ways to connect.  It knows some will fail and some will succeed.  In a normal situation it tries Method 1 (which involved HTTPS), which fails, then Method 2 which succeeds.  And Outlook is happy.

    Now when you put Outlook behind an XG, it tries Method 1.  The XG sees that Method 1 is failing and it wants to give an error message back to the client.  So it does a decrypt on the HTTPS so that it can send back a nice error message.  Outlook sees that Method 1 failed but not for the normally expected reason but because of a certificate.

    An example of this would be if you have scanning turned off and then go to https://asdfasdfdf.com/  The XG does man-in-the-middle to tell you Host Not Found.  I think Matthias Hess described this earlier in the thread (March 5).

    The final solution would possibly be the XG detecting that is Outlook and not sending custom error messages back.
    I don't know if there is a configuration solution in the XG right now.  Possibly if you knew exactly what it was "supposed" to fail at and then putting in a higher firewall rule that just handled that case.