Course menu

Module 6: Security ProfilesLesson 6.2 (2 of 6 in this module)25 of 33 in the FortiGate Administrator course

SSL/TLS inspection

Certificate inspection versus full (deep) inspection, the FortiGate CA, exemptions for privacy and pinned apps, and the certificate warnings that follow mistakes.

Intermediate · 12 min read

What you will learn

After this lesson, you can choose between certificate and deep inspection, make clients trust the FortiGate CA, exempt traffic that must not be decrypted, and explain why users see certificate warnings.

  • Certificate inspection
  • Deep inspection
  • CA trust
  • Exemptions

SSL/TLS inspection decides how a FortiGate handles encrypted sessions. Certificate inspection reads only the unencrypted parts of the TLS handshake (the server name and certificate), enough for web filter categories. Full (deep) inspection decrypts the session: the FortiGate completes TLS with the server, creates a matching certificate signed by its own CA for the client, and can then show the content to antivirus, IPS, application control and web filtering.

In simple terms: Most traffic is locked. Certificate inspection reads the address on the envelope; deep inspection opens the envelope, checks the contents and seals it again, which only works if users trust the FortiGate's seal.

A real-life situation

Nearly all web traffic is HTTPS. FGT1 has antivirus and IPS on the Internet policy, but a test download of the EICAR test file over HTTPS isn't blocked, while the same file over plain HTTP is. Nothing is broken: with certificate inspection the FortiGate never sees the file, only the encrypted stream.

Two levels of inspection

Certificate inspectionDeep inspection
Decrypts?NoYes
SeesServer name (SNI) and certificateFull URLs, pages, files, application data
Web filterBy domain categoryBy full URL, plus content features
AV, IPS, app controlVery limited on HTTPSFull
Client changesNoneClients must trust the FortiGate CA

How deep inspection works

PC1trusts FortiGate CA
FGT1deep inspection
  1. TLS to www.example.com, please.ClientHello from PC1 to FGT1.ClientHello
  2. FGT1 ↔ serverFGT1 opens its own TLS session to www.example.com and validates the real certificate.
  3. Certificatewww.example.com, signed by the FortiGate CA (a copy made on the fly).Certificate from FGT1 to PC1.
  4. Client checkPC1 trusts the FortiGate CA, so the certificate is accepted. If it didn't, the browser would show a warning.
  5. Request and download, encrypted to FGT1, decrypted and inspected, then re-encrypted to the server.HTTPS data from PC1 to FGT1.HTTPS data
The FortiGate runs two TLS sessions: one with the real server (checking its real certificate) and one with the client (presenting a certificate it signs itself). Between them, the content is in clear for inspection.

Configure deep inspection

Simplified illustration of the FortiOS 7.4 GUI · not a screenshot
FGT1Security Profiles › SSL/SSH Inspection

Edit SSL/SSH Inspection Profile: Staff-Deep

Inspection method
SSL Certificate Inspection Full SSL Inspection
CA certificate
Fortinet_CA_SSLEvery client must trust this CA.
Invalid certificates
Allow Block

Exempt from SSL Inspection

Web categories
Finance and Banking Health and Wellness
Addresses
Pinned-Apps
Reputable websites
Off
config firewall policy edit 3 set ssl-ssh-profile "Staff-Deep" next end

Create the profile by cloning the built-in deep-inspection profile, then select it on the policy. Roll it out to a pilot group first.

Making clients trust the CA

  1. Download the CA certificate from the profile page (or use a subordinate CA from your own PKI).
  2. Install it as a trusted root on managed devices with Group Policy, an MDM or your endpoint tool.
  3. Remember applications with their own certificate store (some browsers, Java, developer tools) and guest devices you don't manage: exempt them or don't deep-inspect them.

Exemptions

Exempt traffic that must not or cannot be decrypted: banking and health sites for privacy, apps that pin certificates (some update services and mobile apps), and sites that use client certificates. FortiOS includes a default exemption list of well-known services; review it and add your own.

Inbound: protecting your own server

For traffic to WEB1, there is no need to forge certificates: upload WEB1's real certificate and key to an SSL inspection profile with "Protecting SSL Server", and use it on the Internet-to-WEB1 policy. IPS can then inspect attacks hidden inside HTTPS.

Why it works this way

TLS is designed to stop anyone in the middle reading traffic, and it succeeds. The only way to inspect it is to become a party to the session that the client trusts. That is why deep inspection needs a trusted CA on every client, and why it has privacy, legal and compatibility costs that certificate inspection doesn't.

Common mistakes

  • Enabling deep inspection before the CA is deployed: every HTTPS site shows a certificate warning.
  • Allowing invalid certificates, so users can't tell a real attack from inspection.
  • Not exempting pinned applications, which then fail with vague connection errors.
  • Expecting AV and IPS to protect HTTPS traffic under certificate inspection.

Key takeaways

✅ Key takeaways
  • Certificate inspection reads SNI and the certificate; deep inspection decrypts and re-encrypts.
  • Deep inspection needs the FortiGate CA (or your own subordinate CA) trusted on every client.
  • Exempt privacy-sensitive categories and pinned apps.
  • Inbound to your own server, inspect with the server's real certificate.

Check yourself

Predict · scenario 1

After switching to deep inspection, every HTTPS site shows a certificate warning. What is wrong?

Predict · scenario 2

Which can certificate inspection still do for HTTPS?

Predict · scenario 3

A mobile banking app stops working after deep inspection is enabled. Most likely?

FAQ

Is deep inspection legal?
It depends on the country and on what is decrypted. Many organisations must tell users that traffic is inspected and exempt categories such as banking and health. Agree the policy with HR and legal before turning it on.
Can't I just use the default Fortinet_CA_SSL certificate?
It works once clients trust it, but every FortiGate's default CA is different and self-generated. Many organisations instead issue the FortiGate a subordinate CA from their own internal PKI, which their devices already trust.