7.2 CA Certificates, Port Handling & Inspection Exemptions

7.2 CA Certificates, Port Handling & Inspection Exemptions

Implementing Deep SSL/SSH Inspection in an enterprise environment extends beyond configuring firewall policies. Successful deployment requires a robust Public Key Infrastructure (PKI) strategy, precise control over protocol port definitions, specialized inspection rules for non-HTTP encrypted protocols such as SSH, and comprehensive exemption frameworks to accommodate privacy mandates and applications employing strict security controls.

---

1. PKI & CA Certificate Deployment Architecture

When FortiGate performs Deep SSL Inspection, it re-signs dynamically generated substitute certificates. If the client endpoint does not explicitly trust the CA certificate that signed the substitute certificate, web browsers and operating systems trigger severe security warnings (e.g., NET::ERR_CERT_AUTHORITY_INVALID or SEC_ERROR_UNKNOWN_ISSUER), blocking user access.

                    [ Enterprise AD CS Root CA ]
                                 |
                  (Signs Subordinate CA Request)
                                 v
                     [ FortiGate Subordinate CA ]
                                 |
                 (Dynamically Signs Substitute Certs)
                                 v
  +-------------------------------------------------------------+
  | Domain-Joined Clients (Trust Internal Root CA via AD GPO)   |
  |  ==> Automatically Trust Substitute Certs without Errors!   |
  +-------------------------------------------------------------+

Default Self-Signed CA vs. Enterprise Subordinate CA

• Default Self-Signed CA (Fortinet_CA_SSL): Out of the box, FortiGate generates a local, self-signed Root CA certificate. While suitable for initial testing or small lab environments, deploying this default certificate in an enterprise requires manually distributing and installing Fortinet_CA_SSL.cer into the Trusted Root Certification Authorities store on every single endpoint.
• Enterprise Subordinate CA (Sub-CA - Recommended Best Practice): In an enterprise with an existing Microsoft Active Directory Certificate Services (AD CS) or third-party PKI infrastructure, administrators generate a Certificate Signing Request (CSR) on FortiGate for a Subordinate CA (Sub-CA). The enterprise Root CA signs FortiGate's CSR. Once the signed Sub-CA certificate and chain are imported into FortiGate, all substitute certificates generated by FortiGate chain up to the enterprise Root CA. Because domain endpoints already trust the enterprise Root CA, they automatically trust FortiGate's substitute certificates without requiring any new certificate installation on endpoints.

Endpoint Distribution Methods

For non-domain devices or standalone deployments, CA certificates must be distributed using automated management tools:

1. Active Directory Group Policy Objects (GPO): Pushes the CA certificate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities across all domain-joined Windows machines.
2. FortiClient Fabric Agent / EMS: FortiClient Endpoint Management Server (EMS) automatically pushes and installs FortiGate CA certificates into client operating system stores upon endpoint registration.
3. MDM / EMM Solutions: Microsoft Intune, Jamf Pro, or VMware Workspace ONE deploy configuration profiles containing the CA certificate to macOS, iOS, and Android devices.

Untrusted and Invalid Server Certificate Actions

Within config firewall ssl-ssh-profile, administrators configure how FortiGate responds when external target servers present invalid, expired, or untrusted certificates:

• block (Default/Recommended): FortiGate terminates the connection and presents a customizable replacement blocking page informing the user that the remote certificate is untrusted.
• allow / ignore: FortiGate completes the connection, signing the substitute certificate with a secondary Fortinet_CA_Untrusted CA certificate to trigger browser warnings on the client.
• inspect: Applies standard security profile scanning despite remote certificate errors.

---

2. Custom Port Handling & Multi-Protocol Inspection

Deep SSL/SSH Inspection in FortiOS 7.6 is not restricted to standard HTTPS traffic over TCP port 443. Security profiles support deep inspection across a broad suite of encrypted application protocols:

Custom Port Mapping

Enterprise applications frequently host secure services on non-standard ports (e.g., custom HTTPS on port 8080, 8443, or 9443). In config firewall ssl-ssh-profile, administrators can add explicit custom ports to protocol blocks. Furthermore, in Flow-Based Inspection, setting set ports any instructs FortiGate to perform protocol identification on any TCP port, ensuring encrypted traffic on arbitrary ports is intercepted and inspected.

---

3. SSH Deep Inspection Mechanics

Secure Shell (SSH) provides encrypted terminal access and file transfers over TCP port 22. However, SSH is frequently abused by attackers and insiders to establish encrypted tunnels out of corporate networks, bypassing firewall controls.

FortiGate SSH Deep Inspection offers three distinct protection features:

1. SSH Command Inspection: Inspects interactive shell commands executed within SSH sessions. Administrators can define pattern filters to log or block specific administrative commands (e.g., rm -rf, dd, chmod, sudo su).
2. SSH Tunnel Inspection: Detects and blocks encrypted SSH port forwarding mechanisms—including local port forwarding (ssh -L), remote port forwarding (ssh -R), and dynamic SOCKS proxies (ssh -D). This prevents users from tunneling unauthorized protocols through SSH.
3. SFTP File Inspection: Inspects files transferred via Secure File Transfer Protocol (SFTP), applying Antivirus scanning and Data Loss Prevention (DLP) dictionary rules to outgoing files.

# Configuring SSH Deep Inspection in FortiOS 7.6 CLI
config firewall ssl-ssh-profile
    edit "Enterprise-Deep-Inspection"
        config ssh
            set ports 22
            set status deep-inspection
            set ssh-policy-check enable
            set ssh-tun-policy-check enable
            set unsupported-version block
        end
    next
end

---

4. SSL Inspection Exemptions & Bypass Strategies

While Deep Inspection is critical for threat visibility, decrypting 100% of network traffic is technically impossible and legally problematic. Deep inspection can break applications that enforce SSL Certificate Pinning (where the client application hardcodes the expected server public key fingerprint and rejects FortiGate's substitute certificate). Common examples include financial banking applications, mobile app stores, Apple iOS software updates, Microsoft 365 services, Google Drive sync, Zoom, and video conferencing endpoints.

Additionally, privacy laws (such as HIPAA, GLBA, and GDPR) restrict organizations from decrypting employees' personal financial, health, and legal communications.

Exemption Categories in FortiOS 7.6

FortiGate provides four primary exemption mechanisms within config firewall ssl-ssh-profile under config ssl-exempt:

1. FortiGuard Category Exemptions: Dynamically updated categories provided by FortiGuard. Exclude sensitive web categories such as Finance and Banking, Health and Wellness, and Personal Privacy from decryption.
2. Address / FQDN Exemptions: Exclude specific destination IP addresses, subnets, or Fully Qualified Domain Names (e.g., *.microsoft.com, *.apple.com) from deep inspection.
3. Client IP Exemptions: Exclude specific source devices—such as IoT hardware, VoIP phones, medical equipment, or legacy systems—that cannot support PKI CA certificates.
4. Reputation-Based Exemptions: Automatically bypass inspection for destination domains rated with high FortiGuard Trust/Reputation scores.

# Configuring SSL Inspection Exemptions in FortiOS 7.6 CLI
config firewall ssl-ssh-profile
    edit "Enterprise-Deep-Inspection"
        config ssl-exempt
            edit 1
                set type fortiguard-service
                set fortiguard-service Finance-and-Banking Health-and-Wellness
            next
            edit 2
                set type address
                set address "Microsoft-365-FQDN-Group"
            next
            edit 3
                set type address
                set address "Apple-Update-Servers"
            next
        end
    next
end

---

5. CLI Diagnostics & Troubleshooting Commands

When troubleshooting SSL inspection failures, certificate warnings, or application breakage, FortiOS provides specialized diagnostic commands:

# View Active SSL/SSH Inspection Session Information
diagnose sys session filter dport 443
diagnose sys session list

# Test and Debug SSL-SSH Daemon Operations
diagnose debug application ssl-ssh-profile -1
diagnose debug enable

# Check Installed CA Certificates on FortiGate
execute vpn certificate ca list

# Verify FortiGuard Web Filter Category Lookup for SSL Exemption
diagnose test application urlfilter 1 www.bankofamerica.com