Guide · free to read

FortiGate SSL inspection: full mode vs certificate inspection.

Exam NSE4_FGT_AD-7.6 Written and maintained by Grindstone Prep Last updated 14 September 2026

Most of the traffic a FortiGate sees today is encrypted, which means most of what a FortiGate’s security profiles can actually do — antivirus, IPS, DLP, payload-based application control — depends on one upstream decision: which SSL inspection mode is applied to that traffic. Get this distinction wrong and features you’re relying on can be silently doing nothing, because they never receive anything to inspect. The question worth being able to answer for any given policy is simple to state and easy to get backwards under pressure: “what can FortiGate actually see right now,” and the answer depends entirely on the mode.

Four profiles, one of them editable

FortiOS ships four preloaded SSL/SSH inspection profiles. Three — certificate-inspection, deep-inspection, and no-inspection — are read-only; you can look at them and clone them, but not edit them directly. The fourth, custom-deep-inspection, exists specifically to give you an editable full-inspection profile without having to clone one first. If you want to change what a profile exempts or how it handles untrusted certificates, either work in custom-deep-inspection or clone whichever read-only profile you started from.

Everything below is really a description of two of those profile types: certificate-inspection and deep-inspection (and its editable sibling).

Certificate inspection: reading the handshake, not the traffic

Certificate inspection never decrypts anything. FortiGate’s visibility stops at the TLS handshake — specifically the Server Name Indication (SNI) field the client sends in its ClientHello, which carries the hostname the client is trying to reach. If a client doesn’t send SNI at all, FortiGate falls back to whatever hostname appears in the server certificate’s Subject (CN) or Subject Alternative Name (SAN) field instead.

That’s the entire information budget certificate inspection has to work with, and it explains both what the mode can and can’t do:

• Web filtering works, because FortiGuard categorization only needs a hostname, and SNI (or the certificate CN/SAN as a fallback) supplies one.
• Antivirus and IPS do not work under certificate inspection. Both require reading the actual payload, and certificate inspection never sees the payload — only the handshake.
• The client receives the real server certificate, untouched, which is why certificate inspection produces no browser warnings and needs no trusted CA distributed to endpoints.

One practical consequence worth knowing cold: because the fallback for a missing-SNI client is the certificate’s own CN/SAN, and that name is not always the name the user actually typed (shared hosting, CDNs, and internal load balancers are common cases), certificate inspection can occasionally categorize a site by a name the user never saw — which is why a web-filter block or allow decision under certificate inspection sometimes looks inexplicable until you check what name the certificate itself carries.

Full SSL inspection: FortiGate becomes both endpoints

Full SSL inspection — the deep-inspection profile and its editable sibling custom-deep-inspection — works completely differently. FortiGate terminates the client’s TLS session itself, decrypts the traffic, inspects the actual payload (this is what makes antivirus, IPS, DLP, and payload-based application control possible), opens a second TLS session to the real destination server, and re-encrypts before sending the traffic on. From the client’s point of view it is talking to the real site; from the server’s point of view it is talking to FortiGate.

That re-encryption step needs a certificate, and FortiGate generates one on the fly for each site it inspects, signed by a CA certificate configured on the device. By default that CA certificate is Fortinet_CA_SSL. No browser ships with Fortinet_CA_SSL in its trusted root store, so the first time a client visits any HTTPS site through full inspection, it gets a certificate warning — not because anything is broken, but because the client has never been told to trust the certificate FortiGate just generated.

There are two supported ways to make that warning go away, and only two:

1. Distribute Fortinet_CA_SSL to every client’s trusted root store — typically via Group Policy on a domain-joined fleet — so the certificates FortiGate generates are trusted.
2. Re-sign with a CA certificate issued by your own internal CA instead of the Fortinet default, if your endpoints already trust that CA’s chain (which domain-joined machines usually do already, if the CA is the same one issuing their other internal certificates).

The other direction: protecting a server you publish

Everything above describes the outbound case — a FortiGate inspecting its own users’ traffic out to the internet. There’s a separate, inbound use of full inspection: publishing an internal HTTPS server to the internet through a VIP and wanting antivirus and IPS applied to the inbound sessions. For that case, the profile setting is Protecting SSL Server, not the outbound multi-server mode, and it works differently on purpose. You import the actual server’s certificate — with its private key — onto FortiGate and select it as the profile’s server certificate. FortiGate then uses the real server’s own certificate to impersonate that server to internet clients, which is why this direction produces no certificate warnings at all: the clients are receiving a certificate that really was issued to that hostname. FortiGate decrypts the inbound session using that key pair, applies antivirus and IPS, then opens a second connection to the actual backend server and re-encrypts. It’s the mirror image of the outbound case — outbound impersonates the destination to your users and needs a CA they trust; inbound impersonates your own server to the internet and needs that server’s real key.

The questions worth being able to answer cold

When a user reports a certificate warning, or someone asks why antivirus or IPS didn’t catch something that came in over HTTPS, the useful diagnostic sequence is always the same: which of the four profiles is active on the policy in question, is it actually decrypting anything, what certificate is the client seeing and why, and — if there’s a warning or a blocked connection — whether the fix is a trust problem (who signed the certificate FortiGate handed the client, and does the client trust that signer) or an inspection-mode problem (does this mode even see what you’re trying to inspect). Most SSL-inspection troubleshooting collapses into one of those two categories once you know which mode is actually running.

Sources

Every claim above was checked against one of these Fortinet 7.6 documentation pages. They are free to open, with no account, and checking them is the point of listing them:

• SSL/SSH inspection — the overview.
• Configuring an SSL/SSH inspection profile — the four preloaded profiles and which of them you can edit.
• Certificate inspection — SNI, the CN/SAN fallback, and what this mode can and cannot inspect.
• Deep inspection — full SSL inspection, the re-signing CA, and Fortinet_CA_Untrusted.
• Protecting an SSL server — the inbound case.

Every practice question we publish carries the Fortinet page it was written from, the same way this guide does. You can see fifteen of them, scored by blueprint domain, in the free readiness assessment — it is drawn from the same NSE 4 bank this guide’s subject belongs to, no account, nothing recorded. How they are written is set out on the methodology page, and the catalog says which exams are on sale today.

← All guides