Deep SSL Inspection Breaks Pinned Apps and Saturates the CPU
A FortiGate 400F protects 6,000 users and peaks at 1.2 Gbps internet traffic. Every outbound policy uses one profile group with deep SSL inspection, IPS, antivirus, web filter, and application control. Since deep inspection was enabled, CPU sits at 90-98% at peak, page loads take 8-12 seconds, and Microsoft Teams, a certificate-pinned banking app, and an IoT vendor portal fail. The FortiGate has two 10 Gbps NP7-accelerated ports, and inspection mode is flow-based. The SSL inspection profile exempts only healthcare categories. The security team must keep inspection for general web traffic but cannot break business apps. Logs show many 'ssl cert probe' and 'certificate unknown' events; the FortiGate is not doing SSL offload on a dedicated card. The bank will not provide its certificate chain and the IoT portal uses a self-signed certificate on an IP address.
1. Diagnose the CPU and application failures. Which are expected effects of deep inspection, and which point to a profile design problem?
Read the worked answer
Deep inspection decrypts and re-signs TLS, so it consumes CPU and breaks any application that pins a certificate or expects a self-signed/unknown chain. The banking app is a pinning failure, not a FortiGate bug. The IoT portal on an IP address with a self-signed certificate will also fail deep inspection unless exempted. Teams may fail because of pinning or because the profile is applied to all traffic and the box is overloaded. High CPU at 1.2 Gbps with one profile group on every policy is a design problem: flow-based inspection still has to process every session, and NP7 acceleration does not make deep inspection free. 'ssl cert probe' and 'certificate unknown' events are expected when the client does not trust the re-signing CA or when the server certificate is invalid; they are not proof that inspection is working. The profile should be scoped by risk and application, not applied uniformly.
2. Design an inspection architecture that preserves visibility without breaking pinned and self-signed apps. Address policy ordering, SSL inspection profiles, and exemptions.
Read the worked answer
Create three SSL inspection outcomes: (1) deep inspection for high-risk categories and untrusted destinations; (2) certificate inspection for general web traffic where visibility of SNI/category is enough; (3) no inspection for pinned, self-signed, and business-critical apps that cannot be broken. Put specific firewall policies above the general policy: destination FQDN/IP objects for the bank and IoT portal, application control signatures where possible, and an SSL profile with no inspection or certificate inspection. Within the deep profile, add SSL exemptions for those destinations as a second layer. Use FQDN objects carefully-pinned apps often use many CDN names-so validate with logs and be prepared to exempt by application signature. Do not exempt entire categories such as finance; that removes too much visibility. For the IoT device, a dedicated policy by IP is acceptable because the device is fixed. Document the risk acceptance and log the exempted sessions.
3. What capacity and validation steps would you take before enabling deep inspection again at peak traffic?
Read the worked answer
Baseline before re-enabling: CPU by core, memory, session count, throughput, and SSL sessions at peak. Pilot deep inspection on one user group or one low-risk policy, not all 6,000 users. Use diagnose sys session full-stat, diagnose hardware deviceinfo npu, and SSL debug logs to see whether sessions are accelerated and where they terminate. Test the bank, Teams, and IoT portal explicitly. Re-enable in stages: certificate inspection first, then deep inspection for high-risk categories, then expand. Set a CPU threshold and a rollback trigger. Confirm the FortiGate's CA certificate is deployed to clients if you expect them to trust re-signed sites; otherwise certificate errors will continue. Capacity planning should use measured SSL inspection throughput, not the datasheet firewall throughput.