Configure SSL Inspection and Certificate Pinning Exemptions on a FortiGate

Before you run this

This guide turns on SSL/TLS deep inspection on a FortiGate and then adds exemptions so that applications using certificate pinning (banking apps, Dropbox, Windows/Apple update services, and similar) keep working instead of failing silently. Deep inspection is a man-in-the-middle: the FortiGate decrypts HTTPS, scans it, and re-signs it with its own CA. That is powerful and also the single most disruptive thing you can enable on a firewall.

• Privileges: You need an administrator account with read-write access to Security Profiles, Certificates, and Firewall Policy. A super_admin profile is simplest; a restricted admin profile must include those areas.
• This is not a paste-and-forget change. Read every step. Apply the new profile to one test policy scoped to one test device or a small test group first — never to your catch-all outbound policy on the first pass. Confirm that trusted sites, your line-of-business apps, and update clients all still work before you widen the scope.
• What it changes and what breaks: Clients that do not trust the FortiGate's signing CA will get certificate warnings on every HTTPS site until you deploy that CA to them. Pinned apps will break outright until exempted. This is reversible — you switch the policy back to a lighter profile — but the disruption is immediate while it is live.
• Firewall safety (mandatory): Keep a separate console or out-of-band session open the whole time, because a bad profile applied to the wrong policy can black-hole production traffic. Back up the running configuration before you touch anything. Do this in a maintenance window. FortiOS keeps configuration revisions — your rollback path is restoring the prior revision or your backup file.

What I'm assuming

• FortiOS 7.4, GUI plus CLI access, a unit with a valid FortiGuard subscription (needed for category-based exemptions).
• Managed clients (domain-joined Windows via GPO, or an MDM) where you can push a trusted CA. If you cannot deploy a CA to your clients, deep inspection is the wrong tool — use certificate inspection instead.

Menus and CLI keywords move between FortiOS versions. If a keyword below doesn't match your build, type ? at the CLI to list valid values rather than guessing.

Back up first

In the GUI, open the admin menu (top-right, your login name) → Configuration → Backup, and save the config locally. Confirm you can also see prior states under Configuration → Revisions. Do not proceed until you have a saved backup you can restore.

Two inspection modes — pick deliberately

• Certificate inspection reads the certificate and SNI only. No decryption, so it does not break certificate pinning, but it can't scan payload.
• Deep inspection decrypts everything. Full visibility, but it breaks pinned apps and requires the CA on every client.

This guide sets up deep inspection with exemptions. If you only need SNI/category enforcement, stop here and use the built-in certificate-inspection profile instead.

Choose and deploy the signing CA

The FortiGate re-signs traffic with a CA certificate. You have two standard options:

1. Use the built-in Fortinet_CA_SSL certificate. Simple, but every client must be told to trust it or they get warnings.
2. Import your own subordinate CA (issued from your internal PKI). Cleaner in an AD environment, because clients already trust the root.

Either way, the CA's certificate must land in the client's Trusted Root (or intermediate) store. For domain PCs, push it by GPO. To generate a CSR or import a CA on the FortiGate, use System → Certificates; follow the exact import steps in the Fortinet document "Inspection modes / SSL & SSH inspection" and the certificate management chapter of the FortiOS 7.4 Administration Guide rather than improvising field names.

Create the inspection profile (GUI)

Don't edit the read-only built-in profile — clone it so you can roll back cleanly.

1. Security Profiles → SSL/SSH Inspection.
2. Select deep-inspection, click Clone, and name the copy something obvious, e.g. custom-deep-inspection.
3. Set SSL Inspection Options to Multiple Clients Connecting to Multiple Servers (the normal outbound case).
4. Under CA Certificate, choose the CA you deployed to clients (Fortinet_CA_SSL or your imported sub-CA).
5. Decide how to handle bad server certificates (expired, untrusted). The safe default is Block, but understand that will stop users reaching misconfigured sites. Keep it as it comes from the clone unless you have a reason.

Handle certificate pinning with exemptions

This is the part people skip and then spend a day debugging. Traffic that is exempted is passed through without decryption, which is exactly what a pinned app needs.

In the profile, find the Exempt from SSL Inspection section:

• Enable the Reputable Websites exemption if present — this uses a FortiGuard-maintained list of sites known to break under deep inspection.
• Add the Web Categories you want to pass untouched. Financial and health categories are common choices for privacy and pinning reasons.
• Add specific Addresses. FortiOS ships predefined wildcard-FQDN address objects for common vendors (update services, cloud storage, app stores). Check the exact object names under Policy & Objects → Addresses before adding them — do not assume a name.

The CLI equivalent, if you prefer to script it, is the ssl-exempt table. Verify each keyword with ?:

config firewall ssl-ssh-profile
    edit "custom-deep-inspection"
        config ssl-exempt
            edit 1
                set type wildcard-fqdn
                set wildcard-fqdn "update.microsoft.com"   # use a real predefined object name
            next
            edit 2
                set type fortiguard-category
                set fortiguard-category 31                 # confirm the ID you want in Web Filter
            next
        end
    next
end

Keep Fortinet's current list of pinning-sensitive applications open while you do this — it lives in the FortiGuard/FortiOS documentation and changes over time. When a new pinned app appears, the fix is another exemption entry, not disabling inspection everywhere.

Apply the profile to ONE test policy

1. Policy & Objects → Firewall Policy.
2. Edit a policy whose source is your test device or test group only.
3. Under Security Profiles, enable SSL Inspection and select custom-deep-inspection.
4. Enable at least one scanning profile (Antivirus or Web Filter) — deep inspection only earns its keep when something is actually reading the decrypted flow.
5. Save. Watch your console session stay up.

Verify it worked

• On the test client, browse to an ordinary HTTPS site and inspect the certificate. The Issued By field should now show your signing CA, not the site's real CA. That proves decryption and re-signing are happening.
• If you instead see a certificate warning, the client doesn't trust your CA — fix the CA deployment, don't loosen the profile.
• Test your pinned apps (banking app, cloud storage client, OS update). They should work; if one fails, add its FQDN to the exemption list.
• Log & Report → Security Events / Forward Traffic should show the test policy matching with the inspection profile applied.

Undo / roll back

• Fastest revert: edit the test firewall policy and set SSL Inspection back to certificate-inspection or no-inspection. Traffic returns to normal immediately.
• Full revert: restore the configuration backup or the prior revision you saved before starting (admin menu → Configuration → Revisions).
• To remove the profile itself, first make sure no policy references it, then delete the clone from Security Profiles → SSL/SSH Inspection. Leave the built-in deep-inspection and certificate-inspection profiles alone.

Only widen the profile to production policies once the test scope has run clean through a full business day, including your pinned apps.