Nov 27 2020 06:53 AM
Hi Team,
I need some clarification regarding supportability of SSL decryption on the proxy against specific O365 endpoints.
I understand that MS recommendation is to whitelist all Optimize and Allow endpoint from SSL Decrypt.
But now I'm more interested about in which case is it absolutely required to whitelist from SSL Decrypt?
I know it's a must for EXO Optimize, as Outlook uses certificate pinning, but what about SPO Optimize?
Quoting parts of Managing O365 Endpoints article:
"
Optimization methods include:
Network optimizations for Allow endpoints can improve the Office 365 user experience, but some customers may choose to scope those optimizations more narrowly to minimize changes to their network."
Based on the last sentence I'd assume, that whitelisting Allow endpoints from SSL Decrypt is optional.
As this applies to Allow endpoints only, does it mean that it's a must for Optimize endpoints?
Dec 05 2020 05:19 PM - edited Mar 05 2021 09:48 AM
@Peter Abele If your customer wants to get support for Office 365, we recommend bypassing SSL Break and Inspect for the endpoint categories of Optimize and Allow. If your customer calls Microsoft support with connectivity problems and they have SSL Break and Inspect on these endpoints they should expect to be asked to bypass it. Only Default category endpoints can support SSL Break and Inspect.
We have a test tool for SSL Break and Inspect meeting the recommendations published at https://connectivity.office.com. It will test all Optimize and Allow category endpoints and list any which have SSL Break and Inspect.
You can read public documentation for this at:
Also more details here:
Microsoft 365 Network Connectivity Overview - Microsoft 365 Enterprise | Microsoft Docs
Managing Office 365 endpoints - Microsoft 365 Enterprise | Microsoft Docs
Use third-party network devices or solutions with Office 365 - Office 365 | Microsoft Docs
Please pass this recommended guidance for the best connectivity, user experience, and supportability on to your customer.
Regards,
Paul