SSL Inspection Breaking a Business App
You enable a certificate-inspection (deep) SSL profile on the outbound policy for the Sales department. Within an hour, the ticketing SaaS app fails to load, mobile users report certificate errors, and an internal Java client that pins certificates stops authenticating. Other HTTPS sites work. The profile uses the default FortiGate_CA certificate, exempts the finance category, and applies to all other categories. You need HTTPS visibility for most traffic but must restore the broken app and the pinned client without abandoning inspection entirely.
1. How do you restore the pinned-certificate Java client while keeping deep inspection for general browsing?
Read the worked answer
Pinned clients validate the exact leaf/public-key and will always reject a re-signed certificate, so they must be exempted from deep inspection, not "fixed."
- Identify the client's destination (FQDN/IP) and add it to the SSL profile as an exempt destination (SSL Exemptions list), OR
- Create a higher-priority policy above the inspection policy matching that destination (dst address object) with an SSL profile set to certificate-inspection = no-inspection (or a profile that only logs).
Order matters: the exemption policy must sit above the deep-inspection policy. Keep the deep profile on the general policy for all other traffic. Document the exemption so it's reviewed - pinned apps are a known blind spot, and you're trading visibility for functionality on that one flow only.
2. The SaaS app now fails with certificate errors but the pinned client is fixed. What is the most likely cause and how do you confirm it?
Read the worked answer
The SaaS app likely uses certificate pinning or HSTS with a pinned preload, or it validates against a CA the FortiGate can't chain to (private/enterprise CA or a client that checks the issuer). Mobile users seeing errors on the same app points to pinning/HPKP-style validation rather than a FortiGate CA trust problem (a trust problem would break all inspected sites).
Confirm with the SSL inspection logs / diagnose debug application sslvpn or the forward traffic log filtered to that destination: look for the certificate presented, TLS alerts (e.g., unknown_ca / bad_certificate), and whether the flow is being inspected. Compare a working site vs the failing app in the log to see if inspection is the differentiator. If the app is pinned, add it to SSL exemptions like the Java client. If instead it's a missing CA chain, import the correct root and re-test before exempting.