Fortinet NSE4_FGT_AD-7.6: FortiGate SSL Inspection Tradeoffs

FortiGate SSL inspection creates one of the most important tradeoffs in modern firewall design: security products need visibility into encrypted traffic to inspect malware, applications, and content, while users and applications depend on TLS for confidentiality, identity, privacy, and protocol integrity. Certificate inspection can observe handshake metadata with limited disruption, while deep inspection decrypts and re-encrypts sessions so security profiles can inspect payloads. The stronger visibility comes with higher operational, privacy, certificate, and performance cost.

FortiOS 7.6 continues to support certificate inspection and deep inspection profiles, exemption logic, certificate handling, and inspection interactions with security profiles. Modern applications also use TLS 1.3, QUIC/HTTP3, certificate pinning, mutual TLS, and privacy-sensitive services that can complicate or prohibit interception. The correct design is therefore selective and risk-based rather than “decrypt everything.”

SSL inspection belongs inside Network Security Platforms.

Understand certificate inspection

Certificate inspection examines TLS handshake information such as server certificates without fully decrypting application payloads.

It provides less content visibility but avoids many compatibility and privacy issues of full interception.

FortiGate security profiles may require deeper visibility for payload-based controls, so teams should understand what each profile can and cannot do under certificate inspection.

Understand deep inspection

Deep inspection terminates TLS on the FortiGate and establishes a second encrypted session toward the destination.

Clients must trust the FortiGate’s signing CA for the generated server certificate.

TLS decryption changes what the firewall can see, but it also makes the firewall a sensitive cryptographic intermediary whose certificates and keys need protection.

Plan certificate trust before rollout

Managed endpoints need the appropriate enterprise CA certificate installed through device management or another controlled channel.

Unmanaged devices, external partners, and some embedded systems may not trust the inspection CA and can fail hard.

Do not solve certificate warnings by weakening browser or endpoint validation; fix trust deployment or use an approved exemption.

Expect certificate pinning and mutual TLS exceptions

Some applications validate a specific server certificate or use client certificates in ways that interception breaks.

Maintain narrow exemptions for known incompatible services and review them periodically.

Broad “do not inspect finance/cloud/etc.” categories can become large blind spots if exceptions are created faster than they are retired.

Account for QUIC and modern protocols

HTTP/3 over QUIC changes transport and inspection behavior compared with classic HTTPS over TCP.

Depending on policy and FortiOS capabilities, teams may block, inspect, or force fallback to TLS over TCP for selected use cases.

Test the actual applications because browser behavior and service support can change quickly.

Protect privacy-sensitive traffic

Deep inspection can expose credentials, health data, financial information, personal communications, and other sensitive content to the inspection system and potentially to logs.

Legal, privacy, and HR stakeholders should define categories that must not be decrypted or retained.

Decryption at scale should be designed around both security value and the sensitivity of what inspection reveals.

Plan capacity with inspection enabled

Deep inspection consumes CPU, memory, session state, and cryptographic resources.

Datasheet throughput without equivalent inspection profiles can overstate production capacity.

Measure critical applications with the same TLS versions, security profiles, session concurrency, and logging the firewall will run during normal and HA-failover conditions.

Use exclusions as governed policy

Every exemption should have a reason, owner, scope, and review date.

Where deep inspection cannot be used, compensate with endpoint controls, DNS filtering, EDR, application authentication, or other visibility as appropriate.

An exemption is a security architecture decision, not merely a troubleshooting fix.

Measure whether decryption improves detection

For FortiGate administration, the durable question is whether deep inspection produces enough detection and control value to justify its operational cost on this traffic class.

Use telemetry, incident evidence, user experience, and performance data to tune scope. Selective high-value decryption is often stronger than universal decryption that creates instability and forces operators to add uncontrolled bypasses.

Inspection changes incident evidence. With deep inspection, security profiles can identify payload-level threats that would otherwise be opaque, but logs may also include sensitive URLs or content classifications. Configure logging intentionally so improved visibility does not create an unnecessary secondary store of private data.

Certificate lifecycle is an availability dependency. Monitor the inspection CA and intermediate certificate expiry, protect private keys, and plan rotation before endpoints stop trusting newly generated certificates. In large estates, certificate distribution and rollback should be tested like any other high-impact platform change.

Application owners should participate in pilot testing. Security teams may see successful TLS handshakes while the application fails at an API layer, detects interception, or changes behavior under HTTP/2 versus HTTP/3. Representative business tests reveal issues that a generic web-browsing test never will.

The strongest inspection program stays explainable: what is decrypted, what is exempt, why, which security profiles depend on visibility, what performance budget exists, and how operators identify one failed TLS session. That clarity makes deep inspection a controlled security service rather than a source of unpredictable outages.

Inspection policy should distinguish inbound and outbound use cases. Outbound employee browsing often uses an enterprise CA to generate certificates for external destinations, while inbound inspection for public applications can use the server’s real certificate and private key or another supported reverse-proxy pattern. The ownership, privacy, and certificate lifecycle are different enough that they should not be treated as one generic “SSL inspection” configuration.

Certificate exceptions should be narrower than category exceptions where possible. If one pinned application fails, exempt its specific domain or application path rather than an entire broad category of financial, cloud, or collaboration services. Smaller exemptions preserve more visibility and make later review easier.

Mutual TLS can be especially sensitive because the client certificate participates in authentication. Interception can alter that handshake and break applications that rely on end-to-end client identity. Test mTLS applications separately and prefer bypass when the firewall cannot preserve the required trust semantics safely.

TLS 1.3 reduces some visibility available from older handshake patterns and changes the timing of certificate and key exchange. Security teams should verify how the deployed FortiOS release handles supported TLS 1.3 inspection features and not assume an older TLS 1.2 design behaves identically.

QUIC deserves policy attention because users and browsers can prefer HTTP/3 automatically. If the firewall cannot inspect the required application behavior over QUIC, organizations may choose to block QUIC so clients fall back to TLS over TCP, but that can affect performance. Test the business impact before applying a broad transport policy.

Inspection certificates are high-value keys. Protect the CA private key, restrict administrative access, back up according to policy, and have a revocation and replacement plan. Compromise of an inspection CA can undermine trust far beyond one firewall rule because endpoints have been instructed to trust certificates it signs.

Privacy programs should document who can access decrypted traffic and logs. Deep inspection can expose content that ordinary network operations would never see. Role separation, limited logging, masking, and defined retention can reduce the chance that a security control becomes an unnecessary internal surveillance channel.

Performance testing should include failure scenarios. If one HA member fails, the remaining appliance must carry the entire decryption and inspection load. A design that performs adequately only when both devices share traffic can become unusable precisely when resilience is needed.

Operational support should know how to identify certificate errors quickly. Check certificate chain, issuing CA, hostname, validity, client trust store, exemption policy, and whether the application uses pinning. A fast diagnostic path prevents teams from disabling deep inspection globally to fix one incompatible service.

SSL inspection is therefore a portfolio of selective decisions. Some traffic merits full decryption, some needs certificate inspection, some must be exempt, and some can be protected better at the endpoint or application layer. The strongest program optimizes total detection coverage without sacrificing trust, privacy, or service reliability unnecessarily.

Inspection changes should be released gradually. Start with a representative user or application group, measure certificate errors, application compatibility, CPU, latency, and security detections, then expand. A staged rollout provides time to create narrow exceptions without turning a global decryption policy into a business outage.

Review inspection scope after major application or browser changes. New protocols, certificate pinning, privacy features, or endpoint-managed protections can change the value and compatibility of decryption over time. The inspection program should evolve with the traffic rather than remain fixed after initial deployment.

Security teams should also measure how often exemptions are actually used. An exemption created for one legacy application may remain after that application migrates. Hit data and ownership review can reclaim visibility without increasing user friction.

Keep a documented escalation path for applications that fail under deep inspection. The objective is to diagnose certificate trust, protocol, pinning, or performance quickly and choose the narrowest safe exception rather than disable inspection for an entire user population.

Review certificate, protocol, exemption, and capacity assumptions after every major FortiOS or browser change.

Keep inspection ownership explicit so exceptions and certificate changes never become unowned security debt.

Test the complete user path after every inspection-policy change.