Certificate Pinning Versus Deep Inspection Policy

Do not change policy on the strength of a correlation. The browser working while the application fails is consistent with pinning, but it is also consistent with a proxy-aware browser versus a non-proxy-aware client, an application using a different endpoint or port, or a TLS 1.3 negotiation the build handles differently.

Evidence to gather:

• Compare three clients: a failing BYOD device, a working domain-joined laptop hitting the same application, and the browser on the failing device. If the domain-joined laptop works and the BYOD fails, the difference is the installed CA and the policy that applies to each, not the vendor.
• Packet capture on the FortiGate for one failing session, filtering on the vendor address and port 443, with full packet detail. Look for the client sending a TLS alert such as unknown CA or handshake failure immediately after receiving the server certificate, which is the classic pinning rejection.
• Inspect the certificate chain the client actually receives. Under deep inspection the issuer is the FortiGate or corporate CA rather than the vendor's public CA. Under certificate inspection the real chain passes through untouched, which is why pinning generally survives certificate inspection but fails under deep inspection.
• Confirm the policy path: which profile matches the traffic, whether the destination is rated as expected, and whether an SSL exemption already exists that some users hit.
• Check whether the failures cluster on a FortiOS build, a TLS 1.3 cipher suite, or a client version. That distinguishes a pinning problem from an inspection capability limit.

Only after the capture shows the client rejecting the substituted chain would you scope an exemption.

The proposal would probably fix the application, because certificate inspection passes the vendor's real certificate through and pinning succeeds against it. The cost is that it silently removes content inspection for 800 managed devices, which is exactly the population where you can inspect. You would lose file inspection inside TLS, application-level visibility and most of the value of the malware and web-filter profiles on those policies, and you would be doing it to solve a problem that affects a subset of users and one application.

The blunt instrument is also unnecessary. A targeted design works better:

• Keep deep inspection for managed endpoints with the CA installed, scoped by device or user group rather than by category alone.
• Give BYOD devices a policy with certificate inspection only. They cannot be deep-inspected anyway without the CA, and pretending otherwise just produces errors.
• Create an SSL exemption or a policy placed above the deep-inspection rule for the specific vendor destination, identified by FQDN or an address object built from the vendor's published ranges, with logging enabled so the exemption is visible rather than invisible.
• Compensate for the blind spot with application control, endpoint protection on managed devices, and logging of the SNI for exempted flows so you still know who connected where.
• Keep uncategorised traffic under deep inspection only for devices that can support it, since that category is where unknown risk concentrates.

The judgement is that a scoped exemption with monitoring is a smaller, more defensible risk than a global downgrade that trades away visibility for all managed users.

Treat it as a separate fault until proven otherwise. Intermittent errors across several sites after a signature or rating update suggests a chain or categorisation issue rather than pinning.

Diagnose by error type first. Ask for the exact browser message: unknown issuer, name mismatch and expired certificate have different causes and different fixes. Then capture a failing handshake and compare three things: the chain the server sends, the chain the FortiGate presents to the client, and the CA certificate installed in the client trust store. A missing intermediate in what the FortiGate presents is a common cause of intermittent failures, because some clients can fetch intermediates and others cannot.

Next, check whether the FortiGuard update changed the category or action for the affected destinations. A site moving from a category handled by certificate inspection to one handled by deep inspection will start showing errors for users whose devices lack the CA. Review web-filter logs for the affected destinations around the time the errors started and compare the action and profile applied before and after.

Then check the inspection CA itself: expiry, whether it was regenerated, and whether the new certificate was distributed to clients. If the firewall CA was replaced without updating the endpoint deployment, every deep-inspected site breaks intermittently as clients hit cached versus fresh trust decisions.

Resolve by fixing the cause: install the complete chain, correct the category-based policy so finance devices with the CA are consistently deep-inspected, and redistribute the CA through the management tool. Do not disable inspection or set the profile to allow invalid certificates to make the errors disappear; that converts a visible failure into a silent security gap.