Deep inspection breaks pinned business applications

The distinguishing factor is the trust store and certificate pinning, not the network path.

Reasoning

• Domain PCs received the Fortinet CA by GPO, so a browser can validate the re-signed certificate and browsing works.
• Teams, Outlook mobile, and the Salesforce desktop client either use their own certificate store, or pin the expected issuer/public key, or both. They see a certificate issued by Fortinet where they expect Microsoft or Salesforce, and abort the handshake or fail the sign-in loop.
• Guest Wi-Fi works because certificate-inspection does not re-sign anything; it only reads the server certificate and SNI, so pinned clients see the real certificate chain.

Confirm before changing profiles

1. Filter logs by the affected destinations and look for TLS handshake failures or SSL-exempt/blocked events.
2. From a test client, compare openssl s_client -connect <dest>:443 -servername <host> through the firewall against the same command from an unfiltered path; note the issuer.
3. Test the same app on guest Wi-Fi to prove the profile, not the app or the ISP, is the variable.

Deep inspection cannot coexist with certificate pinning for a given destination. The design must therefore be explicit about which flows are decrypted and which are only inspected at the certificate/SNI level.

Recommended structure

1. Put a dedicated policy above policy 5 for the pinned SaaS destinations, using destination ISDB objects such as Microsoft 365 and the Salesforce address group. Give it ssl-ssh-profile certificate-inspection, but keep IPS, application control, and web filter. Those profiles still work on SNI, certificate metadata, and flow behaviour without decrypting payload.
2. Keep policy 5 with deep-inspection for general internet traffic, so ordinary browsing, file downloads, and unknown destinations remain decrypted.
3. Alternatively, add ssl-exempt entries inside the deep-inspection profile for the same ISDB groups. Choose one approach, not both, so the behaviour is easy to audit.
4. Make sure QUIC/UDP 443 is blocked by application control so those apps fall back to TCP 443, where certificate inspection at least applies.

Trade-offs to state plainly

• Exempted flows lose antivirus, file filtering, and payload-level IPS. Compensate with endpoint protection, SaaS API-based CASB controls, and restricted access to those destinations.
• ISDB objects change over time; review the exemptions quarterly and test after FortiGuard updates.
• Splitting policies increases rule count and requires careful ordering; document why each exemption exists.

Forcing TCP 443 does not remove pinning; it only removes QUIC as an additional complication.

Points to make

• Pinning is an application decision about which certificate chain it will accept. A pinned client on TCP 443 still rejects the Fortinet-issued certificate. Moving off QUIC makes the flow visible to the firewall but not acceptable to the client.
• Blocking QUIC is still worth doing, because UDP 443 cannot be decrypted and would otherwise bypass deep inspection entirely. But it is a visibility measure, not a fix for pinning.

Verify after any change

1. That each app actually falls back to TCP 443 and still works; some clients retry, some fail permanently.
2. That the QUIC block is scoped, not a blanket UDP deny, so other legitimate UDP services are unaffected.
3. That TLS 1.3 and any encrypted-client-hello behaviour do not hide the SNI the certificate-inspection policy depends on.
4. That the exemption policy is logged, so the security team can quantify exactly how much traffic is not decrypted and present that risk to the business.