4.1 Inspection Modes & SSL Inspection
Key Takeaways
- Flow-based inspection samples packets as they pass through and favors throughput; proxy-based inspection reconstructs the full file or transaction before scanning and favors detection depth.
- Security profiles (AntiVirus, Web Filter, Application Control, IPS, and others) do nothing until they are referenced by an accept firewall policy with inspection enabled.
- Certificate inspection reads only the unencrypted TLS handshake (SNI and the server certificate) and never decrypts traffic; full (deep) SSL inspection decrypts, scans, and re-encrypts the session.
- Full SSL inspection requires the FortiGate CA certificate to be trusted on every client, or users receive certificate warnings.
- SSL exemptions let you skip decryption for sensitive or incompatible categories such as Health and Wellness, Finance, and pinned-certificate applications.
Why Inspection Modes Matter
A FortiGate firewall can permit a connection and still let malware, phishing pages, or banned applications through if the traffic is never examined. Content inspection is the layer that opens packets, reconstructs the payload, and compares it against threat intelligence. The Content Inspection domain is the single largest part of the Fortinet NSE 4 exam at roughly 25 percent of questions, and almost every scenario starts with the same two choices: which inspection mode and how much of the encrypted traffic can the FortiGate see.
FortiOS 7.6 supports two inspection modes that determine how a security profile processes traffic.
Flow-Based Inspection
Flow-based inspection examines packets as they stream through the FortiGate. The IPS engine scans content in real time without buffering the entire file or web page. Because nothing is held back, flow-based inspection introduces the least latency and the highest throughput, and it is the default mode in FortiOS 7.x.
- Single-pass IPS engine scans antivirus, IPS, application control, and web filtering signatures together.
- Lower memory and CPU overhead; better for high-bandwidth links.
- Cannot reliably hold a file to render a replacement message; blocked web pages may show a TCP reset rather than a styled block page in some cases.
Proxy-Based Inspection
Proxy-based inspection terminates the connection on the FortiGate, buffers the complete object (a file, an email, a web page), scans it as a whole, and then forwards it. Because the FortiGate has the full object, it can apply features that need complete context.
- Full client/server proxy enables features such as content disarm and reconstruction (CDR), deeper antivirus options, and rich, styled replacement pages.
- Higher latency and memory use because objects are buffered before delivery.
- Required for some advanced AntiVirus and DLP-style behaviors.
The mode is set per Virtual Domain (VDOM) under System > Settings > Inspection Mode, and individual profiles indicate which mode they support. On the exam, remember the trade-off in one sentence: flow-based optimizes speed, proxy-based optimizes thoroughness.
Flow-Based vs Proxy-Based Inspection
| Characteristic | Flow-Based Inspection | Proxy-Based Inspection |
|---|---|---|
| How traffic is handled | Packets scanned as they stream through | Connection terminated; full object buffered, then forwarded |
| Latency / throughput | Low latency, high throughput | Higher latency, lower throughput |
| Resource use | Lower CPU and memory | Higher CPU and memory |
| Detection depth | Signature scanning in real time | Whole-object analysis, most thorough |
| Replacement messages | Limited; may use TCP reset | Full styled block/replacement pages |
| Advanced features | Single-pass IPS engine | CDR, deeper AV options, richer DLP behavior |
| Default in FortiOS 7.6 | Yes (default) | Optional, set per VDOM |
Exam tip: If a question asks which mode gives the most thorough content analysis or supports a styled block page, the answer is proxy-based. If it asks which mode gives the best performance or lowest latency, the answer is flow-based.
How Security Profiles Attach to Firewall Policies
A security profile is a reusable configuration object — AntiVirus, Web Filter, DNS Filter, Application Control, IPS, File Filter, Email Filter, and others. A profile by itself inspects nothing. It becomes active only when a firewall policy with Action: ACCEPT references it.
The workflow is:
- Create or edit a firewall policy and set the Action to ACCEPT (deny policies cannot carry inspection).
- Enable the desired security profiles on that policy and choose the profile to apply.
- Select the SSL/SSH Inspection profile, because encrypted traffic must be inspected through an SSL inspection profile for the security profiles to see inside it.
- FortiOS applies profile groups or individual profiles to all sessions matched by that policy.
Because profiles are applied per policy, two different policies can enforce different protection levels — for example, a strict Web Filter on a guest network policy and a lighter one on a server policy. If a security profile is configured but no policy references it, it has zero effect on traffic. This is a common troubleshooting point on the exam.
SSL/TLS Inspection
Most web traffic is now encrypted with Transport Layer Security (TLS). Encrypted payloads are opaque, so AntiVirus and Web Filter cannot examine the content of an HTTPS session unless the FortiGate first applies an SSL/SSH Inspection profile. FortiOS offers two levels.
Certificate Inspection
Certificate inspection (sometimes called SSL certificate inspection) is the lightweight option. The FortiGate never decrypts the session. It reads only the unencrypted parts of the TLS handshake:
- The Server Name Indication (SNI) field in the ClientHello.
- The Common Name (CN) and Subject Alternative Name (SAN) of the server certificate.
From those fields the FortiGate can apply FortiGuard web-category filtering and block by hostname, but it cannot scan the payload for malware or specific URLs inside the page. There is no client certificate warning because the original server certificate is passed through untouched.
Full (Deep) SSL Inspection
Full SSL inspection, also called deep inspection, performs a controlled man-in-the-middle. The FortiGate:
- Intercepts the client's TLS request and establishes its own TLS session to the real server.
- Decrypts the traffic, exposing URLs, files, and content to every security profile.
- Re-encrypts the traffic to the client using a certificate signed by the FortiGate CA certificate.
Full inspection is required for AntiVirus to scan downloaded files over HTTPS, for Web Filter to match full URLs and keywords, and for Application Control and IPS to see encrypted application data. The cost is higher CPU use and the operational requirement that clients trust the FortiGate CA.
The SSL Certificate Trust Chain
When the FortiGate re-signs traffic, the client's browser validates the new certificate against its trust store. If the FortiGate CA certificate (the built-in Fortinet_CA_SSL or a custom intermediate CA) is not installed as a trusted root, the browser shows a certificate warning on every site.
To avoid warnings, administrators deploy the FortiGate CA certificate to every client — commonly through Active Directory Group Policy or a mobile device management tool. The trust chain becomes: client trusts FortiGate CA -> FortiGate CA signs the re-issued server certificate -> browser accepts the session. For unmanaged or BYOD devices where you cannot push the CA, certificate inspection is the practical choice.
The allow-invalid-cert (untrusted SSL certificate) setting controls what the FortiGate does when the real server presents an invalid or expired certificate: it can allow, block, or warn. The allow-invalid-cert option lets sessions to servers with bad certificates continue rather than being dropped.
SSL Exemptions
Deep inspection is not always desirable. SSL exemptions tell the FortiGate to skip decryption for specific traffic and let it pass with certificate inspection or no inspection. Common reasons:
- Privacy and compliance — exempt categories such as Health and Wellness, Finance and Banking, and Personal Privacy so sensitive data is never decrypted.
- Certificate pinning — many applications (banking apps, software updaters, some Google and Apple services) pin a certificate and break if the FortiGate substitutes its own. Exempting them keeps them working.
- Performance — exempt large trusted streaming services to save CPU.
Exemptions are configured in the SSL/SSH Inspection profile by FortiGuard category, by specific address, or by hostname/wildcard.
Certificate Inspection vs Full SSL Inspection
| Characteristic | Certificate Inspection | Full (Deep) SSL Inspection |
|---|---|---|
| Decrypts traffic? | No | Yes (intercept, decrypt, re-encrypt) |
| What it can see | SNI, certificate CN/SAN only | Full URLs, files, keywords, payload |
| Client CA certificate needed? | No | Yes — FortiGate CA must be trusted |
| Certificate warnings | None | Yes, unless the FortiGate CA is deployed |
| AntiVirus over HTTPS | Not effective | Fully effective |
| Web Filter scope | Category/hostname only | Category, full URL, and keyword filtering |
| Performance impact | Low | Higher (CPU for crypto) |
| Best for | BYOD, privacy-sensitive traffic | Managed corporate endpoints |
Exam tip: The key limitation of certificate inspection is that it cannot inspect the content of an encrypted session — it only sees handshake metadata. If a question describes malware slipping through HTTPS or a need to match a full URL path, full SSL inspection is required.
Which statement best describes the difference between flow-based and proxy-based inspection on a FortiGate?
An administrator enables full SSL inspection on a firewall policy. Users immediately report certificate warning errors on every HTTPS site. What is the most likely cause?
Why might an administrator add an SSL exemption for an online banking category in the SSL/SSH Inspection profile?