Sophos XG breaks SSL when connecting to Outlook Anywhere

This has not worked for me.  I have turned off the microapp-discovery yet I am still getting the security alert for autodiscover.  Since the "issued by" says Sophos SSL i think the problem is with the router.

Any other suggestions?

The issue is caused by the XG sending the traffic to the Web Proxy, which then does SSL man-in-the-middle in order to show a friendly error message.

One reason for the traffic being sent to Web Proxy is that flag, but there are other reasons.  Most of them have to do with your firewall rules.

Make sure in your firewall rules there is a high-level rule that would apply to this traffic, but that has HTTPS Decrypt and Scan off and Web Policy None.

Thank You Michael!

After spending an extremely long time on this going through Certficate and VPN settings I thoguht I would bite the bullet and try your fix.

Ran the command

system application_classification microapp-discovery off

as suggested and boom, outlook issues stopped instantly as well as an issue I had with HTTPS traffic going across our site to site VPN.

Glad to hear it.

I'll have people know I am, today, testing the permanent fix for this.  Basically it will turn it off that flag for everyone, but then do several other things to make sure application classification, including all web-based application detections ("microapps") still work.  It is currently scheduled for an upcoming 16.05 MR but I don't know when.

It will also thankfully remove the concept of "microapps" for administrators (although still have it internally).

Hi MatthiasHess,

In new version of SFOS, the firewall break automatically any invalid (auto generated) certificate even if you don't check HTTPS decryption in the firewall policy. to resolve this problem, I suggest you sign the Exchange certificate with known authority, or if you want keep your self-signed certificate, you can unchecked "Block invalid certificates" under Web --> Protection --> HTTPS Decryption and Scanning.

XG 16.05 MR4 has a fix included (NC-13909) in it that improves the situation.

On all boxes that5 upgrade to XG 16.05 MR4, the microapp-discovery flag in console has been migrated to be off by default.
That means if you have no firewall rules that apply to HTTPS (port 443), then the HTTPS traffic should flow across with no interruption and the httpproxy will not try to give friendly error messages - which is the fix that was already presented here as a workaround.
There are some additional changes in order to update application detection in HTTPS.  For example, in the UI the "Enable micro-app discovery" flag on Application Control filters is removed.

If you want to use application detection then it respects your firewall rules.  
If you have no firewall rules for HTTPS (port 443), then applications that use HTTPS are not detected.  
If you have a firewall rules for HTTPS, but no decryption, then applications that use HTTPS are detected only by domain name only (eg Facebook).  
If you have a firewall rules for HTTPS, with decryption, then applications that use HTTPS are detected only by full URL (eg Facebook Chat).  

Anyone who has already implemented the workaround posted in this thread does not need to do anything.  However for reference the correct settings for all users with MR4 is:
system application_classification microapp-discovery off
system application_classification on

Hi Mathias,

I was trawling through this thread, trying in vain to get a result, and discovered one thing I didn't check - DNS records.

For our organisation, we had an autodiscover CNAME record set to autodiscover-s.outlook.com. This was all very well and ensured autodiscover worked, but it kept giving the certificate issue. This was even with the SSL appliance cert pushed out to all clients.

I found that removing the CNAME record and exchanging it for an SRV record ( _tcp, port 443) on our DCs resolved our issues completely.

Might be obvious to some, but it's another place to look if you do get stuck!