FortiGate SSL Deep Inspection: Design, Configuration and Troubleshooting

Modern enterprise web traffic is almost entirely encrypted using Transport Layer Security (TLS). While this protects data privacy, it creates a massive operational blind spot for security teams. Cyberattacks, malware command-and-control communications, and data exfiltration techniques routinely hide behind valid TLS encryption. FortiGate SSL deep inspection addresses this challenge by decrypting, inspecting, and re-encrypting network traffic in real time. This process allows deep security profiles like Antivirus, Intrusion Prevention System (IPS), Web Filtering, and Application Control to inspect payload contents that would otherwise pass through completely unmonitored.

Implementing full TLS decryption requires precise architectural planning, active certificate management, and operational safeguards. This technical tutorial covers the design, step-by-step configuration, traffic processing, and systematic troubleshooting workflow required to deploy deep inspection safely in enterprise environments.

Real-Life Scenario

An enterprise organization wants to secure outbound internet access for its corporate workstations. The organization must enforce strict threat prevention profiles against malware and unauthorized data leaks. However, the security team faces three primary constraints:

• Visibility: Security profiles must inspect HTTPS traffic to detect payloads and URL parameters.
• Privacy & Compliance: Sensitive site categories—specifically Finance and Banking and Health and Wellness—must be excluded from decryption to comply with privacy laws.
• Operational Stability: Applications that enforce Certificate Pinning (such as Microsoft Teams, Zoom, and cloud storage agents) must not break when deep inspection is enabled.

To satisfy these requirements, the engineering team will deploy a custom Subordinate Certificate Authority (CA) on the FortiGate, distribute the issuing certificate to all endpoints via Active Directory Group Policy (GPO), and configure a FortiGate SSL deep inspection profile with targeted exemptions.

Lab Topology

The following diagram illustrates the network path between the internal endpoint, the FortiGate firewalls performing Man-in-the-Middle (MITM) decryption, and the destination web server on the public internet.

+--------------------------------+
|  Corporate Endpoint (Client)   |
|  IP: 192.0.2.50                |
|  Trusts: Enterprise Sub-CA     |
+---------------+----------------+
                |
                | [HTTPS Port 443]
                v
+---------------+----------------+
|  FortiGate Next-Gen Firewall   |
|  Interface port2: 192.0.2.1    |  <--- Intercepts TLS Session
|  Interface port1: 198.51.100.2 |   Re-encrypted Session]
                v
+---------------+----------------+
|  Internet / Remote Web Server  |
|  IP: 203.0.113.50              |
+--------------------------------+

Example Addressing and Objects

The network parameters and FortiOS configuration objects used in this tutorial are detailed in the table below. Note that production deployment values must be adapted to your specific IP addressing scheme and PKI hierarchy.

Prerequisites

Before configuring FortiGate SSL deep inspection, ensure that the following baseline requirements are met in your environment:

• Active Directory PKI / Private CA: You need an Enterprise Root or Intermediate Certificate Authority capable of issuing an Subordinate CA certificate with Key Usage set to Digital Signature, Certificate Signing, and CRL Signing.
• Certificate Deployment: The Root CA and any Intermediate CAs must be pre-installed in the Trusted Root Certification Authorities store on all managed endpoints. Unmanaged or personal devices (BYOD) will receive browser certificate warnings if this trust anchor is missing.
• FortiOS Baseline: This guide targets FortiOS version 7.0 and higher. Note that interface layouts and GUI options can vary slightly across hardware models and release branches.
• Hardware Offloading Awareness: Content inspection switches processing from network processors (NP) to content processors (CP9/CP10) or software SSL engines. Ensure CPU overhead is factored into firewall capacity planning.

Step-by-Step GUI Configuration

Step 1: Import the Subordinate CA Certificate

To inspect encrypted sessions without causing untrusted certificate warnings, the FortiGate must sign generated site certificates on the fly using a certificate trusted by clients.

1. Log in to the FortiGate administrative GUI.
2. Navigate to System > Certificates. (Note: If Certificates is not visible, enable it under System > Feature Visibility > Certificates).
3. Click Import > Local Certificate.
4. Select Certificate as the import type, upload the PKCS#12 (.pfx or .p12) file containing the Subordinate CA private key and certificate, and enter the password.
5. Verify that the imported certificate status displays as OK and lists appropriate usage permissions. Rename the certificate object to Enterprise_SubCA for clarity.

Step 2: Create the SSL/SSH Inspection Profile

Now, construct the custom inspection profile to define how HTTPS traffic is handled, exempted, or blocked.

1. Navigate to Security Profiles > SSL/SSH Inspection.
2. Click Create New in the top menu.
3. Set the Name to Deep_Inspection_Enterprise.
4. Under SSL Inspection Options, set the Inspection Method to Full Inspection (or Deep Inspection depending on FortiOS release).
5. Set the CA Certificate dropdown to your imported certificate: Enterprise_SubCA.
6. Configure the protocol settings for HTTPS:
   • Inspect All Ports: Enabled (or specify target port 443).
   • Untrusted SSL Certificates: Select Block to protect internal endpoints from expired or invalid external certificates.
7. Under Exempt from SSL Inspection, toggle URL Category to Enable. Select categories to bypass, such as Finance and Banking and Health and Wellness.
8. Toggle Addresses and Address Groups or FortiGuard Reputable Websites to enable built-in system exemptions for known applications that use certificate pinning.
9. Click OK to save the security profile.

Step 3: Apply the Inspection Profile to the Firewall Policy

The inspection profile takes effect only when applied to an active firewall policy handling outbound internet traffic.

1. Navigate to Policy & Objects > Firewall Policy.
2. Locate policy ID 10 (or create a new policy) permitting outbound LAN-to-WAN traffic.
3. Set Incoming Interface to port2 and Outgoing Interface to port1.
4. Set Source to CORP_LAN_192.0.2.0_24 and Destination to all.
5. Set Service to HTTPS, HTTP, and DNS.
6. Scroll down to Security Profiles and toggle the switch to enable profiles.
7. Enable SSL Inspection and select Deep_Inspection_Enterprise from the dropdown.
8. Enable supplementary security profiles, such as Antivirus, Web Filter, and Application Control.
9. Ensure NAT is enabled, then click OK.

CLI Configuration

For network engineers deploying via automation, scripts, or SSH, the equivalent FortiOS CLI syntax is provided below. This syntax applies directly to standard FortiOS 7.x code streams.

Step 1: Configure the SSL/SSH Profile

config firewall ssl-ssh-profile
    edit "Deep_Inspection_Enterprise"
        set comment "Corporate SSL Deep Inspection with Exemption List"
        set server-cert-mode re-sign
        set can-sign-ca "Enterprise_SubCA"
        set untrusted-cert block
        config https
            set ports 443
            set status deep-inspection
            set client-certificate bypass
        end
        config ftps
            set status disable
        end
        config imaps
            set status disable
        end
        config pop3s
            set status disable
        end
        config smtps
            set status disable
        end
        config ssh
            set status disable
        end
        config ssl-exemption
            edit 1
                set type fortiguard-service
                set fortiguard-service 11 15
            next
        end
    next
end

Note: FortiGuard service IDs 11 and 15 map to “Finance and Banking” and “Health and Wellness” in standard FortiOS database revisions. Always confirm mapping on your specific device.

Step 2: Apply Profile to Firewall Policy

config firewall policy
    edit 10
        set name "Outbound_Corporate_Access"
        set srcintf "port2"
        set dstintf "port1"
        set action accept
        set srcaddr "CORP_LAN_192.0.2.0_24"
        set dstaddr "all"
        set schedule "always"
        set service "HTTPS" "HTTP"
        set utm-status enable
        set ssl-ssh-profile "Deep_Inspection_Enterprise"
        set av-profile "default"
        set webfilter-profile "default"
        set application-list "default"
        set nat enable
    next
end

How the Traffic Flows

Understanding the internal session creation and packet handling sequence helps engineers isolate performance or connectivity issues faster.

1. Session Initiation: The corporate endpoint (192.0.2.50) initiates a TCP 3-way handshake to destination host 203.0.113.50 on port 443.
2. Policy Match & Route Lookup: The FortiGate inspects the SYN packet, identifies an outgoing route via port1, and matches firewall policy ID 10.
3. Client Hello Interception: The client sends a TLS Client Hello packet. The FortiGate proxy daemon (sslprx) intercepts the packet.
4. Server SNI & Exemption Check: The FortiGate evaluates the Server Name Indication (SNI) extension against configured exemptions (e.g., banking domains or pinned application lists).
   • If exempted: The FortiGate steps out of the middle, allowing a direct, un-intercepted TLS tunnel to form. Decryption does not occur.
   • If NOT exempted: The process continues to step 5.
5. Upstream Handshake: The FortiGate opens an independent TLS connection to the actual web server (203.0.113.50) to validate its certificate chain, cipher suites, and trust status.
6. Dynamic Certificate Generation: The FortiGate takes the server’s real identity (e.g., example.com) and generates a temporary certificate on the fly, signing it with the internal Enterprise_SubCA private key.
7. Downstream Handshake: The FortiGate completes the TLS handshake back to the internal client using this freshly minted certificate.
8. Decrypted Inspection: Data sent between client and server is converted to cleartext within the FortiGate engine memory, allowing UTM engines (AV, IPS, Web Filter) to evaluate payload content.
9. Re-encryption and Egress: The FortiGate re-encrypts clean traffic and sends it out over interface port1 to the destination.

Verification

Verify that SSL deep inspection operates as expected using both client-side and FortiGate system checks.

1. Client Browser Verification

Open a web browser on endpoint 192.0.2.50 and navigate to a non-exempt site (e.g., https://example.com). Click the padlock icon in the browser address bar and inspect the certificate details:

• Issued To: example.com
• Issued By: Enterprise_SubCA (Your internal Intermediate CA name).

If the certificate hierarchy reflects your local CA and no browser untrusted warning appears, decryption and endpoint trust are functioning perfectly.

Next, navigate to a banking site (e.g., an exempted domain). Inspect the certificate again:

• Issued By: DigiCert, Let’s Encrypt, or another public CA.

This confirms that the bypass engine correctly matches and bypasses exempted traffic categories.

2. Active Session Inspection via CLI

Check the active firewall session table on the FortiGate to verify that the profile is attached to real-time traffic sessions:

diagnose sys session filter src 192.0.2.50
diagnose sys session filter dport 443
diagnose sys session list

Look for session output lines indicating proxy handling and SSL profile attachment, such as:

...
proto=6 proto_state=01 state=log may_dirty ndr auth offer_sdata npu_bypass
statistic(bytes/pkts/mask): total=4215/28/1 orig=2012/14/1 redir=2203/14/1
...
helper=https security_profile_list: ssl-ssh:Deep_Inspection_Enterprise
...

Troubleshooting

Deploying SSL deep inspection frequently uncovers application incompatibilities or trust issues. Follow this structured approach to diagnose issues.

Symptom 1: Client Browser Shows “NET::ERR_CERT_AUTHORITY_INVALID”

• Likely Cause: The endpoint does not trust the signing CA configured on the FortiGate.
• Diagnostic Step: On the Windows endpoint, run certutil -store Root or check certmgr.msc to verify whether Enterprise_SubCA or its parent Root CA exists in the **Trusted Root Certification Authorities** container.
• Resolution: Re-deploy the CA certificate to endpoints via Active Directory GPO, Intune, or MDM framework.

Symptom 2: Proprietary Application Fails to Connect (Certificate Pinning)

• Likely Cause: Applications like Dropbox, Spotify, or cloud syncing clients check for hardcoded public certificates and reject proxy certificates.
• Diagnostic Step: Enable real-time SSL proxy debugging on the FortiGate while reproducing the connection attempt.

diagnose debug reset
diagnose debug application sslprx -1
diagnose debug enable

Observe the debug stream for failed handshake records or alert messages such as fatal alert: unknown CA or proxy connection resets.

After observing the issue, disable the debug trace safely:

diagnose debug disable
diagnose debug reset

• Resolution: Add the destination domain or IP subnet to the SSL inspection profile bypass list under Addresses and Address Groups or Custom Categories.

Symptom 3: High CPU Load on FortiGate After Enabling Profile

• Likely Cause: High volume of concurrent SSL sessions pushing software processing limits.
• Diagnostic Step: Check process usage for the proxy daemon and overall CPU breakdown:

diagnose sys top 2 20

Observe if processes such as sslprx or wad consume excessive CPU percentage.

• Resolution: Ensure that high-bandwidth, non-threat traffic (such as internal backup endpoints, video streaming, or trusted software updates) is separated into distinct firewall policies where SSL deep inspection is turned off.

Common Mistakes

• Inspecting All Traffic Universally: Enabling deep inspection on a blanket policy without excluding financial, health, and pinned-app domains will inevitably break core user applications and spark end-user complaints.
• Forgetting Certificate Revocation Lists (CRL): If the internal CA cannot be validated or lacks an accessible CRL distribution point, modern browsers may reject re-signed certificates.
• Using the Default Fortinet Factory Certificate: Relying on the default internal Fortinet_CA certificate for deep inspection forces every end-user browser to display untrusted warnings until manually imported across all endpoints. Always use an internal PKI subordinate certificate.
• Ignoring TLS 1.3 Drafts and ECH: Encrypted Client Hello (ECH) masks the SNI header. If ECH is active on client browsers, domain-based exemptions will fail unless disabled via browser administrative templates or DNS policy.

Production Considerations

To maintain performance, availability, and regulatory compliance, review these operational guidelines before rolling out deep inspection at scale:

• Phased Rollout: Do not enable deep inspection globally in a single change window. Deploy the profile to a pilot User Acceptance Testing (UAT) subnet first. Expand to additional organizational units (OUs) over 3–4 weeks.
• Sizing and Offloading: Review hardware platform specifications. FortiGate desktop and mid-range enterprise models include CP9 or CP10 co-processors that accelerate TLS decryption. Ensure your current model has sufficient throughput capacity for proxy-based UTM loads.
• Legal Exemption Policy: Work directly with corporate legal and HR teams to document exempted site categories clearly. Post a clear Acceptable Use Policy (AUP) notifying employees that corporate internet access is subject to decrypted security monitoring.
• Bypass List Maintenance: Maintain a operational runbook for adding custom domain exceptions quickly when cloud providers update application endpoints or implement strict certificate pinning.

Related FortiGate Guides

• Apply FortiGate security profiles to firewall policies
• FortiGate session troubleshooting
• FortiGate packet sniffer and debug flow
• FortiGate Syslog and SIEM integration

Summary

Deploying FortiGate SSL deep inspection removes critical visibility blind spots, allowing enterprise security teams to detect advanced threats hiding inside encrypted HTTPS streams. By leveraging an enterprise PKI subordinate certificate, applying selective category exemptions, and monitoring proxy daemons, administrators can implement rigorous content filtering without disrupting key business operations or compromising user privacy.