NSE7 Part 7: Security Profiles at Scale: SSL/SSH Inspection and UTM Performance

Security profiles is the lightest domain on the NSE 7 blueprint, 5-15% of the exam, and that weighting is itself informative. NSE4 tests whether you can configure a web filter profile or an IPS sensor. NSE 7 assumes you already can, and instead tests two narrower, more expensive-to-get-wrong questions: when does SSL inspection strategy actually matter, and what does stacking security profiles cost the platform.

What UTM Actually Costs You already covers the NP7/CP9 hardware-offload mechanics of deep inspection in detail. This post assumes that background and stays on the two blueprint tasks specifically: SSL/SSH inspection profile strategy, and the combined performance and false-positive picture of running web filtering, application control, IPS, and ISDB together.

Certificate Inspection vs. Full Inspection

FortiOS offers two fundamentally different SSL inspection modes, and the exam’s framing treats picking the wrong one for a given requirement as a design failure, not a minor misconfiguration.

Certificate inspection (formerly “SSL handshake inspection” in older documentation) reads only the TLS handshake, specifically the SNI field and the server certificate’s CN/SAN, without decrypting the session payload at all. FortiGate can enforce URL/category filtering and application identification based on the hostname alone, with zero decryption, zero re-encryption, and essentially no added latency or CPU cost beyond ordinary packet inspection. What it cannot do: inspect content inside the encrypted payload, which means no IPS pattern matching against the actual HTTP body, no antivirus scanning of a downloaded file’s real content, no DLP against what’s actually being transmitted.

Full inspection (deep inspection) terminates the client’s TLS session at the FortiGate, inspects the decrypted payload, and re-encrypts toward the real server using a FortiGate-generated certificate signed by a CA the client must trust. This is what makes IPS, AV, and DLP actually see real content rather than an opaque encrypted blob, at the cost of genuine CPU work (or NP7/CP9 hardware offload where the platform supports it) and, more consequentially for the exam’s design questions, the CA-trust-distribution requirement covered below.

The design decision the blueprint is testing: certificate inspection is correct wherever the requirement is category/reputation-based control (block gambling sites, allow only approved SaaS categories) and full inspection is required wherever the requirement is content-based control (scan downloaded files for malware, DLP against outbound data, IPS signature matching against payload). A design proposing full inspection everywhere “to be safe” is not automatically the right answer on this exam, because full inspection carries real costs the next two sections cover, and a requirement that only ever needed category filtering doesn’t justify paying them.

Server Certificate SNI Check

The SNI check feature validates that the SNI value presented in the TLS ClientHello actually matches the certificate the server subsequently presents, catching a specific evasion technique where a client deliberately sends a benign SNI value (to pass certificate-inspection-mode category filtering) while actually connecting to a different, policy-violating server. With SNI check enabled, a mismatch between the claimed SNI and the actual presented certificate triggers the configured action (block, or log-only depending on policy strictness).

This matters specifically for certificate-inspection-mode deployments, since certificate inspection’s entire filtering decision rests on trusting the SNI value at face value. Full inspection mode is inherently immune to SNI-spoofing evasion, since it sees the actual destination and actual certificate regardless of what SNI was claimed, which is one more data point supporting full inspection wherever the security requirement genuinely needs it rather than a cost to accept everywhere by default.

Multiple Clients to Multiple Servers, vs. Protecting SSL Servers

FortiOS distinguishes two inspection topologies that use full inspection differently:

Multiple clients connecting to multiple servers: the ordinary outbound web-browsing scenario, where FortiGate sits between internal clients and arbitrary external servers. This is the case full inspection with a FortiGate-generated CA and client-side trust distribution is built for: one CA certificate, distributed to every managed client (via GPO, MDM, or the FortiClient endpoint), lets FortiGate transparently re-sign every outbound session without individual client warnings.

Protecting SSL servers (inbound, reverse-proxy-style inspection): a specific internal server’s own TLS certificate and private key are imported directly into FortiGate, which terminates client connections using the server’s real identity rather than a FortiGate-generated one. This is the correct mode for protecting a single known server (a web application, an internal service) where client trust in the server’s own certificate must be preserved exactly, and the FortiGate is inspecting inbound traffic toward that server rather than outbound traffic from arbitrary internal clients.

Conflating these two modes, or applying the outbound multiple-clients-multiple-servers profile to an inbound server-protection scenario, breaks certificate trust for the protected server’s real clients, since those clients would see a FortiGate-generated certificate instead of the server’s actual one. The exam expects the topology (outbound client traffic vs. inbound traffic toward a known server) to determine which profile shape applies, not a single generic “full inspection” setting reused everywhere.

Dealing with False Positive Events

Full inspection’s re-signing behavior breaks a specific, recurring category of legitimate traffic: certificate pinning. Applications that pin a specific expected certificate or public key (many mobile apps, some desktop software, certain API clients) reject FortiGate’s re-signed certificate outright, since it doesn’t match the pinned value, regardless of whether the FortiGate’s CA is otherwise trusted. This shows up as application failures that look like network problems from the user’s side, and the fix is not a FortiGate misconfiguration to hunt for, it’s an SSL inspection exemption for that specific destination (config firewall ssl-ssh-profile exempt list, matched by FQDN, IP, or predefined exemption categories Fortinet maintains for known pinning applications).

HTTP and HTTPS code injection: some security profile actions (replacement messages, certain web filter block pages) inject content into the HTTP response stream. Under full inspection this happens transparently; under certificate inspection, where FortiGate never sees the actual response body, injection isn’t possible at all, and block actions are limited to the connection-level (reset, drop) rather than a rendered block page. A design expecting a branded block page shown to the end user needs full inspection to deliver it; certificate inspection alone cannot.

Certificate errors on FortiGate: the specific, recurring troubleshooting use case named in the blueprint: a user reports a browser certificate warning, and the diagnostic question is whether it’s a genuine problem with the real destination’s certificate (expired, wrong CN, untrusted CA, the same as it would be with no FortiGate in the path at all) or a symptom of the FortiGate’s own CA not being trusted by that specific client (the client never received the CA cert via GPO/MDM, or is a personal/unmanaged device that was never enrolled). Distinguishing the two starts with diagnose sys ssl-ssh-profile or checking whether the failing certificate’s issuer is the FortiGate’s own CA name at all, and it’s a common enough real-world troubleshooting scenario that the exam treats it as a distinct skill, not just SSL inspection trivia.

Performance: The Combined Security Profile Stack

The blueprint’s second security profiles task, using web filtering, application control, IPS, and ISDB together, is explicitly framed around impact on firewall performance, not configuration of any individual profile. The relevant facts:

• On NP-equipped platforms, security profile inspection is a genuine data-plane cost even with NP offload, because NP hardware offloads forwarding and stateful inspection, not content inspection. IPS, AV, and application control signature matching happen on the CPU regardless of NP offload for the surrounding session, which is the single most commonly tested performance fact in this domain: NP7/CP9 offload does not make UTM free.
• Device performance scales differently per profile type. Application control and ISDB matching are comparatively cheap (metadata/signature matching against already-parsed session information). IPS and full-inspection-dependent AV are comparatively expensive (payload-level pattern matching against every byte of decrypted content). A design under-provisioned for its actual security profile stack shows up as increased latency and, at the extreme, session drops under load, not a clean failure mode that’s obvious to diagnose from a single symptom.
• CVE-pattern IPS sensors specifically (as opposed to a broad default IPS sensor covering every signature category) are the blueprint’s named example of scoping IPS cost deliberately: an IPS sensor scoped to signatures relevant to the actual server OS/application stack behind a policy costs meaningfully less to evaluate than the full default signature set applied indiscriminately, without sacrificing coverage for threats that are actually relevant to what’s being protected.

The design judgment underneath this whole section, consistent with the FortiGuard tuning discipline covered elsewhere on this site: security profile stacking is not a binary “more is safer” decision. Every profile added to a policy is both a security control and a performance cost, and an enterprise design sized against expected throughput needs to account for the actual profile stack a policy runs, not just the platform’s headline throughput figure measured with no UTM enabled at all.

Part 8 leaves security profiles behind and moves into the domain the blueprint weights heaviest alongside advanced IPsec: routing, starting with OSPF’s FortiOS-specific pieces.