After enabling deep SSL inspection, Teams calls started failing and OneDrive sync stopped working for all 200 users simultaneously.
The Failure Pattern We Saw First
My team rolled the change into production on a Tuesday morning after testing normal web browsing, ERP access, and a few vendor portals behind a FortiGate running FortiOS 7.4.3. We had Ubuntu 22.04 jump boxes, Windows clients, and a Python 3.11 script checking policy hits through the FortiGate API. The firewall looked healthy. The policy counters moved. The CA certificate was deployed through our domain GPO.
Then the help desk queue filled in 11 minutes. Teams showed call setup failures, meetings joined without audio, and OneDrive sat on “Processing changes” until users gave up. Before the change, we had 200 of 200 users syncing and joining calls normally. After the change, we had 0 of 200 users able to complete both Teams calling and OneDrive sync.
That was not a small failure.
My wrong first assumption was that we had missed the FortiGate inspection CA on a subset of machines. We checked certificate stores, browser trust, endpoint profiles, and proxy settings. The real issue was simpler and less negotiable: Microsoft Teams pins certificates and rejects re-signed certificates from intermediate CAs like the FortiGate inspection CA. There is no way to make Teams work under deep inspection.
I think deep inspection is still useful in a manufacturing network, but treating Office 365 like ordinary HTTPS traffic is a bad bet.
Which Microsoft Traffic We Stopped Inspecting
We started by separating Microsoft 365 traffic into two buckets: traffic we could inspect without breaking user workflows, and traffic that needed certificate inspection exemptions because the application expected Microsoft’s real certificate chain. Teams and OneDrive were the obvious failures, but I also included SharePoint Online, Exchange Online, Microsoft login endpoints, and related Office CDN traffic because partial exemptions create strange authentication loops.
What I didn’t expect was how often a broken Teams experience depended on endpoints that did not look like “Teams” in a firewall log. Authentication, media negotiation, file preview, presence, and sync all pulled from different Microsoft-owned ranges and service tags. Looking only for teams.microsoft.com was not enough in our environment.
Our exemption list focused on these service families:
- Microsoft Teams signaling, media, and meeting services
- OneDrive for Business sync and file transfer
- SharePoint Online document libraries and previews
- Exchange Online authentication and mailbox access
- Microsoft 365 login, activation, and Office CDN endpoints
The practical answer was to exempt the Microsoft 365 service ranges, not chase individual hostnames one outage at a time. That is the only approach I trust at plant scale.
Using FortiGuard Office 365 Objects
On FortiOS 7.4.3, I used FortiGuard’s Office 365 Internet Service Objects because Microsoft changes addresses too often for a static address group to age well. I have seen hand-built Microsoft allowlists become wrong within a maintenance cycle, and when that happens the firewall becomes the mystery variable in every collaboration ticket.
We confirmed that the FortiGate had current FortiGuard Internet Service Database updates, then built policy logic around Microsoft service objects. The goal was not to bypass security controls blindly. The goal was to avoid re-signing certificates for applications that reject re-signed certificates by design while keeping normal web traffic under deep inspection.
Precision mattered.
The final production design used a dedicated SSL/SSH inspection profile with Microsoft 365 exemptions and a normal deep inspection profile for the rest of outbound HTTPS. After configuring SSL inspection exemptions for all Microsoft O365 IP ranges using FortiGuard’s Office 365 address objects, all Teams and OneDrive functionality restored immediately.
I prefer FortiGuard-maintained objects here because operational drift is the real enemy, not the first configuration.
Configure Exemptions Without Turning Inspection Off
I did not disable deep SSL inspection globally. That would have fixed the outage, but it would also have removed the visibility we needed for malware inspection, risky downloads, and unmanaged web services on the production VLANs. We built a narrower exception path and kept the rest of the security profile intact.
config firewall ssl-ssh-profile
edit "deep-inspection-with-o365-exemptions"
set comment "Deep inspection except Microsoft 365 pinned certificate services"
config ssl-exempt
edit 1
set type fortiguard-category
set fortiguard-category 140
next
end
next
end
config firewall policy
edit 42
set name "Users-to-Internet-Deep-Inspection"
set srcintf "corp-lan"
set dstintf "wan1"
set srcaddr "Manufacturing-Users"
set dstaddr "all"
set action accept
set schedule "always"
set service "HTTPS" "HTTP"
set utm-status enable
set ssl-ssh-profile "deep-inspection-with-o365-exemptions"
set webfilter-profile "standard-web"
set av-profile "default"
set logtraffic all
next
endThe exact object names vary by FortiGate build and database version, so I verified the available Office 365 Internet Service entries on the appliance before committing the policy. In our environment, I also logged the exempted sessions for the first week because I wanted proof that the exception was catching Microsoft traffic and not becoming a broad bypass.
That logging paid for itself.
We found a few older production PCs still using stale Office builds that behaved differently from current Microsoft 365 Apps. Those endpoints were not the root cause, but they made troubleshooting noisier. My opinion is blunt: SSL inspection rollout belongs with endpoint version cleanup, not after it.
How We Proved the Fix
We tested from three places: a normal office workstation, a shop-floor shared station, and an Ubuntu 22.04 admin host using browser-based Microsoft 365 checks. I watched FortiGate session logs while another engineer started Teams calls, uploaded files to OneDrive, opened SharePoint documents, and signed out and back into Office. We also used a Python 3.11 script to query policy hit counts every 30 seconds during the test window.
The verification criteria were plain. Teams had to join meetings with audio and video, OneDrive had to sync new and modified files, Outlook had to authenticate without repeated prompts, and SharePoint had to open documents from links inside Teams. I did not accept “the portal loads” as a pass because the failure we hit was not a simple portal failure.
Before the exemption, Teams call completion sat at 0 successful test calls out of 12 attempts. After the exemption, we completed 12 successful test calls out of 12 attempts, and OneDrive synced a 1.4 GB test folder in 6 minutes 18 seconds. That gave us enough confidence to reopen the policy for all 200 users.
Numbers ended the debate.
I still think deep inspection should be introduced in controlled rings, even when the configuration looks obvious. The outage taught me that certificate-pinned SaaS traffic can fail cleanly, quickly, and everywhere at once.
Test Before Production Rollout
My current rollout pattern is slower than the one we used that morning. I now put Microsoft 365 exemptions in place before enabling deep inspection for user VLANs, then I test Teams, OneDrive, SharePoint, Outlook, and browser sign-in from representative machines. I also check FortiGate logs for certificate inspection actions because a passed user test without firewall evidence is weaker than it feels.
For our manufacturing facility, the best balance is selective inspection: inspect ordinary HTTPS traffic deeply, exempt Microsoft 365 pinned-certificate services, and keep the exemption maintained through FortiGuard objects instead of static IP lists. That gives my team usable visibility without breaking the collaboration tools the plant depends on every shift.
My opinion after this incident is simple: deep SSL inspection is a scalpel, not a blanket.