FortiGate SSL inspection interview questions (FortiOS 7.6)

Q1Fresher

Compare certificate inspection and deep inspection.

Certificate inspection reads only the SNI and the server certificate from the TLS handshake, and decrypts nothing. Deep inspection decrypts the session, so web filtering sees full URLs and antivirus, IPS and application control see the content.

Why it matters

The choice decides what your security profiles can act on. Deep inspection needs every client to trust the FortiGate’s CA, and it costs CPU.

Prove it in the lab

FGT-HQ # show full-configuration firewall ssl-ssh-profile certificate-inspection
FGT-HQ # show full-configuration firewall ssl-ssh-profile deep-inspection

Look for: The HTTPS status in each built-in profile: certificate-inspection in the first, deep-inspection in the second.

Common wrong answer

“Certificate inspection decrypts a little of the traffic.” It decrypts nothing. A browser still shows the site’s public issuer, because nothing is re-signed.

Likely follow-up

Which built-in profiles exist? no-inspection, certificate-inspection and deep-inspection. Clone one, or build your own, when you need changes.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q2Fresher

With certificate inspection, what can a FortiGate still block in HTTPS, and what can it not?

It can read the server certificate and block a site by its hostname or FortiGuard category. It cannot see URL paths or files, because nothing inside the session is decrypted.

Why it matters

Certificate inspection needs no client changes, so it is easy to roll out. Many applications inside TLS can be recognised from the SNI; others, or sub-functions of an app, need deep inspection.

Prove it in the lab

FGT-HQ # show firewall policy 1

Then, on WIN-PC, open https://www.fortinet.com and view the certificate’s issuer.

Look for: set ssl-ssh-profile "PML-Cert-Inspect" on the policy, and a public CA as the issuer, not the FortiGate.

Common wrong answer

“You can block one path, such as /downloads/setup.exe, on an allowed site.” Path-level blocking needs deep inspection; certificate inspection sees only the hostname.

Likely follow-up

What can the web filter see with the no-inspection profile? No HTTPS hostname at all. See HTTPS not filtered.

Practise this in Labs 8 and 9 of the FortiOS 7.6 course.

Q3Fresher

How do you make Windows clients trust the FortiGate’s inspection CA?

Download Fortinet_CA_SSL from System > Certificates and import it into the computer’s Trusted Root store. In production, push it with Group Policy so every domain PC trusts it.

Why it matters

Deep inspection works without warnings only when clients trust the re-signing CA. Only the certificate leaves the FortiGate; the private key stays on it.

Prove it in the lab

PS C:\> Import-Certificate -FilePath "$env:USERPROFILE\Downloads\<downloaded-file>" `
>> -CertStoreLocation Cert:\LocalMachine\Root
PS C:\> Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*Fortinet*"

Look for: The last command lists the FortiGate CA, and certlm.msc shows it under Trusted Root Certification Authorities. The Group Policy path is Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Import.

Common wrong answer

“Double-click the certificate and install it.” That is a common way to land it in the current user’s Personal store, which Windows does not use to trust servers.

Likely follow-up

Should clients also trust Fortinet_CA_Untrusted? Never install it on clients; it exists so that bad server certificates still cause a warning.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q4Experienced

How does deep inspection work, and why must clients trust the FortiGate CA?

The FortiGate splits the connection into two TLS sessions and re-signs the server’s certificate with its own CA, Fortinet_CA_SSL by default. Clients accept the re-signed certificate only if that CA is in their trusted root store.

Why it matters

The FortiGate decrypts, inspects and re-encrypts the data between the two sessions. If it signs with an enterprise sub-CA instead, clients must trust the enterprise root CA that issued it.

1. WIN-PC sends a TLS ClientHello, and the matching policy uses a deep-inspection profile.
2. The FortiGate opens its own TLS session to the server and validates the real certificate.
3. It creates a certificate with the same names, signed by Fortinet_CA_SSL, or by the untrusted CA if validation failed.
4. WIN-PC accepts it only if it trusts the signing CA.
5. The decrypted data goes to flow or proxy inspection, then is encrypted again.

Prove it in the lab

FGT-HQ # show full-configuration firewall ssl-ssh-profile PML-Deep-Inspect | grep caname

Then, on WIN-PC, open any inspected site’s certificate.

Look for: caname "Fortinet_CA_SSL" in the profile, and the FortiGate CA as the issuer in the browser.

Common wrong answer

“The FortiGate decrypts with the server’s private key.” That is inbound inspection of your own server. For outbound traffic, the FortiGate re-signs with its own CA.

Likely follow-up

What if the real certificate is invalid? See invalid server certificates.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q5Experienced

What happens under deep inspection when the real server certificate is invalid?

FortiOS re-signs it with a separate CA, Fortinet_CA_Untrusted, which clients do not trust, so the browser still warns. Re-signing a bad certificate with the trusted CA would hide the problem from the user.

Why it matters

The profile also sets actions for untrusted, expired and revoked certificates, validation timeouts, unsupported TLS versions and certificate probe failures. In 7.6.0, the default for cert-probe-failure changed to allow.

Prove it in the lab

FGT-HQ # show full-configuration firewall ssl-ssh-profile PML-Deep-Inspect | grep -i cert

Look for: The certificate check actions, server-cert-mode re-sign and, on 7.6, cert-probe-failure allow.

Common wrong answer

“No warning appears, because the FortiGate re-signs every certificate with the trusted CA.” Only certificates that pass validation get Fortinet_CA_SSL.

Likely follow-up

What does a user see on an internal site with a self-signed certificate? A browser warning, because the FortiGate signs its copy with Fortinet_CA_Untrusted.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q6Experienced

What should you exempt from deep inspection, and how?

Exempt sensitive categories such as banking and health for privacy, and applications that pin their certificates. An exemption can match a FortiGuard category, an address, a wildcard FQDN or a regex.

Why it matters

A pinned application accepts only its own server’s certificate, so re-signing breaks it. Category exemptions need FortiGuard ratings.

Prove it in the lab

FGT-HQ # config firewall ssl-ssh-profile
    edit "PML-Deep-Inspect"
        config ssl-exempt
            edit 1
                set type wildcard-fqdn
                set wildcard-fqdn "<wildcard-fqdn-address-object>"
            next
        end
    next
end

Look for: The exempt entry in the profile. An exempted site shows its own public issuer in the browser again.

Common wrong answer

“Exempt every category that causes trouble.” Exempting everything removes inspection; exempt only what pins certificates or must stay private.

Likely follow-up

Which apps break under deep inspection besides pinned ones? Apps that use client certificates, and some update services.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q7Experienced

How do you inspect HTTPS traffic to your own internal web server?

Import the server’s certificate and private key, then apply an SSL/SSH profile with server-cert-mode replace to the VIP policy. Clients see the genuine certificate, so no CA deployment is needed.

Why it matters

IPS and antivirus then see the decrypted requests aimed at your server. An IPS sensor on the VIP policy needs this to see inside HTTPS requests.

Prove it in the lab

FGT-HQ # config firewall ssl-ssh-profile
    edit "PML-Inbound"
        set server-cert-mode replace
        set server-cert "<imported-server-certificate>"
    next
end
FGT-HQ # config firewall policy
    edit 3
        set ssl-ssh-profile "PML-Inbound"
    next
end

Look for: server-cert-mode replace with your imported certificate, and the profile on the VIP policy.

Common wrong answer

“Use the deep-inspection profile and push the FortiGate CA to clients.” Internet clients are not yours to manage; replace mode presents your server’s real certificate instead.

Likely follow-up

Which server certificate mode is the default? re-sign, which is for outbound inspection.

Practise the SSL/SSH profile work in Lab 8 of the FortiOS 7.6 course.

Q8Experienced

Why is QUIC a problem for SSL inspection, and how does FortiOS 7.6 handle it?

QUIC carries HTTP/3 over UDP 443 with TLS 1.3 built in, so classic TLS-over-TCP inspection does not see it. In 7.6, deep inspection inspects QUIC by default through the profile’s quic setting, while certificate inspection always bypasses it.

Why it matters

The quic setting under config https takes inspect, bypass or block, with inspect the default since 7.4.2. With certificate inspection only, block QUIC with application control, and browsers fall back to HTTPS over TCP.

Prove it in the lab

FGT-HQ # diagnose sys session filter proto 17
FGT-HQ # diagnose sys session filter dport 443
FGT-HQ # diagnose sys session list

Look for: UDP 443 sessions. Once QUIC is blocked, they disappear and the application control log shows the block.

Common wrong answer

“A FortiGate cannot inspect QUIC at all.” Since 7.4.2, deep inspection inspects it by default; only certificate inspection bypasses it.

Likely follow-up

Why do the course’s web tests use curl.exe? It never uses QUIC, so HTTP/3 cannot confuse the results.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q9Experienced

You run several FortiGates. Which CA should sign the inspection certificates?

Use one enterprise sub-CA, imported into each FortiGate, so endpoints trust one issuer instead of one CA per firewall. Otherwise each FortiGate signs with its own Fortinet_CA_SSL.

Why it matters

Every FortiGate generates its own Fortinet_CA_SSL, so a fleet would mean many CAs to deploy. With a sub-CA, endpoints must trust the enterprise root CA that issued it.

Prove it in the lab

FGT-HQ # show full-configuration firewall ssl-ssh-profile PML-Deep-Inspect | grep caname

Look for: The caname line names the CA that signs re-issued certificates. System > Certificates lists the CAs the FortiGate holds.

Common wrong answer

“Install every FortiGate’s own CA on every PC.” It works, but it adds one more trusted issuer for every firewall.

Likely follow-up

What is a sub-CA? A CA signed by your company’s own root CA.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q10Scenario

After you enable deep inspection, users see certificate warnings and some apps stop working. What do you do?

Warnings on every site mean endpoints do not trust the FortiGate CA, so deploy it to their trusted root store. Apps that break while browsers work usually pin certificates or use client certificates, so exempt them.

Why it matters

A warning on one site only usually means its real certificate is bad and was re-signed with the untrusted CA. That is correct behaviour, so read the pattern before you change anything.

Prove it in the lab

PS C:\> Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*Fortinet*"

FGT-HQ # show full-configuration firewall ssl-ssh-profile PML-Deep-Inspect | grep caname

Look for: An empty Trusted Root query on an affected PC, or a caname that the PCs do not trust.

Common wrong answer

“Switch the profile’s CA to Fortinet_CA_Untrusted.” That CA exists to cause warnings. Falling back to certificate inspection is no fix either, because it cannot scan inside HTTPS.

Likely follow-up

How do you push the CA to every domain PC? With Group Policy. See trusting the FortiGate CA.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q11Scenario

The CA was installed on a PC, but every HTTPS site still shows a warning. What went wrong?

Check which store the certificate went into. A common mistake is installing it for the current user, in the Personal store, which Windows does not use to trust servers.

Why it matters

The certificate is present, so the problem looks like a FortiGate fault. Import it into Cert:\LocalMachine\Root again and restart the browser.

Prove it in the lab

PS C:\> Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*Fortinet*"
PS C:\> Get-ChildItem Cert:\CurrentUser\My | Where-Object Subject -like "*Fortinet*"

Look for: Nothing from the Trusted Root query, and the FortiGate CA in the Personal store. In the browser, the chain ends at an untrusted FortiGate CA.

Common wrong answer

“Regenerate the FortiGate CA.” The certificate is fine; only its store is wrong, and a new CA would need deploying again.

Likely follow-up

How do you avoid this at scale? Push the CA with Group Policy instead of installing it by hand.

Practise this in Lab 8 of the FortiOS 7.6 course.

Q12Scenario

A web filter blocks a site over HTTP, but the same site loads over HTTPS. The policy uses the no-inspection profile. Why?

With no-inspection, the FortiGate does not read the SNI or the certificate name, so it cannot filter HTTPS hostnames. Attach a certificate-inspection profile, and the web filter can block the hostname.

Why it matters

HTTP needs no TLS inspection, so the HTTP test passes and hides the gap. Only deep inspection shows full HTTPS URLs.

Prove it in the lab

FGT-HQ # show firewall policy 1
FGT-HQ # config firewall policy
    edit 1
        set ssl-ssh-profile "PML-Cert-Inspect"
    next
end

Look for: The policy’s SSL/SSH profile before the fix; use show full-configuration if a default value is hidden. Then repeat the HTTPS test.

Common wrong answer

“The web filter does not support HTTPS.” It does, once the policy uses at least certificate inspection.

Likely follow-up

Which SSL/SSH profile does a new policy use? no-inspection is the default for a policy’s ssl-ssh-profile.

Practise this in Lab 9 of the FortiOS 7.6 course.

Q13Scenario

An EICAR test download over HTTPS is not blocked, but the same file over HTTP is. What do you check?

Check the policy’s SSL/SSH profile first: certificate inspection reads only the handshake, so antivirus never sees a file inside TLS. Use deep inspection with a CA the clients trust, and check the site is not exempt.

Why it matters

The HTTP test already proves the signature works, which splits the problem quickly. Then check that the AV profile’s HTTP scanning is set to block, because decrypted HTTPS is scanned as HTTP. Also confirm utm-status is enabled and the file is below the oversize limit.

Prove it in the lab

FGT-HQ # show firewall policy 1
FGT-HQ # show antivirus profile PML-AV
FGT-HQ # diagnose firewall iprope lookup 10.10.10.100 50000 192.0.2.100 443 tcp port2

Look for: The SSL/SSH and AV profiles on the policy, av-scan block under HTTP, and the policy ID the lookup returns.

Common wrong answer

“The signatures are out of date.” The HTTP test proves the signature; the HTTPS session was simply never decrypted.

Likely follow-up

Is there a separate HTTPS option in the AV profile? No. Decrypted HTTPS is scanned as HTTP.

Practise this in Labs 8 and 10 of the FortiOS 7.6 course.

Q14Scenario

Deep inspection is attached, but HTTPS sites still show their own public certificates. What do you check?

First confirm the session matches that policy and the site is not exempt. Then check the licence: a low-encryption unit, such as the FortiGate-VM permanent trial, cannot perform SSL inspection.

Why it matters

Tell a licence limit from a configuration fault before you change a correct profile. Fortinet’s low-encryption notes say such units also cannot act on encrypted traffic.

Prove it in the lab

FGT-HQ # get system status
FGT-HQ # diagnose debug vm-print-license

Look for: The licence the VM runs. If it is the low-encryption trial, repeat the test on a licensed VM.

Common wrong answer

“The deep-inspection profile is broken, so rebuild it.” The profile and policy can be correct while the licence is the limit.

Likely follow-up

Does certificate inspection work on the trial? You can build and attach it, but no Fortinet document confirms that the trial filters HTTPS hostnames with it.

Practise this in Lab 8 of the FortiOS 7.6 course.