Modern HTTPS hides much of the information a security gateway once saw in cleartext. On FortiGate, detecting a malicious download or enforcing a category decision may depend on what the firewall can inspect without breaking valid TLS connections. Certificate inspection and full SSL/SSH deep inspection are not interchangeable, and the difference is explicitly tested by Fortinet’s NSE 4 FortiOS 7.6.0 content-inspection objectives. A good answer recognizes both the information available and the trust consequences of decrypting traffic.
What certificate inspection can and cannot see
Certificate-oriented inspection uses connection and certificate information without necessarily decrypting an entire application session. That can support some destination or category decisions, but it cannot inspect the full plaintext payload of an encrypted web response. If a file download carries malware inside a trusted HTTPS connection, a control requiring payload visibility may have less evidence when only certificate information is available. Do not equate a successful TLS handshake with an antivirus scan of everything transferred.
Full deep inspection is different: FortiGate terminates and re-establishes encrypted sessions in a controlled way, examining permitted plaintext content under an approved inspection profile. That can enable more detailed inspection but changes the trust boundary and raises privacy, compatibility and certificate-management concerns. Fortinet’s deep inspection deployment documentation describes distributing a trusted CA certificate and selecting it in SSL/SSH inspection profiles as part of a deliberate deployment.
Trust chains are configuration dependencies
Clients validate the certificate chain presented for the inspected session. If endpoints do not trust the enterprise CA that FortiGate uses for interception, users may see certificate warnings or outright application failures even though the firewall and upstream site are reachable. An administrator should distribute a managed trusted certificate using approved endpoint controls and verify expiration, revocation and private-key protection. Importing a root CA into an unmanaged machine just to make a test succeed is not a sound rollout strategy.
When a browser warns of an untrusted issuer only on inspected traffic, compare the chain presented to the client with the endpoint’s trust store. Other root causes include incorrect time, hostname mismatches, unsupported ciphers or a server’s actual certificate problem. Fortinet’s certificate administration reference describes CA and remote-certificate management; the corrective action depends on which validation stage fails.
Plan exceptions without discarding the protection
Some applications use certificate pinning, mutual TLS or protocols that do not tolerate interception. Banks, medical platforms and regulated workloads may also have privacy constraints. A carefully approved exception can be appropriate, but it must name the business reason, affected destination or application, owner, expiry and compensating controls. An exception for one certificate-pinned client should not become a blanket exclusion for all encrypted traffic from the user’s network.
Before implementing an exclusion, verify whether the failure truly originates in deep inspection. Check the firewall policy match, network route, DNS resolution and the security log that recorded the blocked or failed transaction. If the session never reached an inspection profile, modifying SSL/SSH settings cannot solve it. Conversely, if a flow is accepted but web filtering blocks a prohibited category, adding a second allow rule will not override the security decision.
Web filtering and FortiGuard categories
Web filtering can apply FortiGuard category lookups, local URL conditions and profile-specific actions according to configured inspection mode. The ability to identify a category does not necessarily grant payload inspection. FortiGuard connectivity, licensing, policy binding and rule order must all be correct for an intended web-filter action to occur. In flow-based versus proxy-based inspection, feature support and processing behavior differ; validate a particular feature against the installed FortiOS version rather than assuming every profile behaves identically.
Use a test URL from an authorized lab to demonstrate an allow, an intentionally blocked category and a locally overridden decision. Check the exact security profile that produced each event. The existing security profiles and UTM guide supplies broader antivirus, IPS and application-control context, while the log investigation guide explains how to separate a web-filter log from a generic traffic record.
Design an encrypted-traffic lab with boundaries
Start with one managed test client, a controlled HTTPS destination and a baseline firewall policy. Record whether normal certificate inspection succeeds. Then deploy a lab CA and an SSL/SSH inspection profile, distribute the CA to that test client, and repeat the request. Collect the client-visible certificate issuer, FortiGate traffic result and web-filter log. After making a controlled exception for a known incompatible test application, prove that the exception is limited to the intended destination.
Remove the test CA trust and observe the resulting certificate failure; restore it only using an approved procedure. Never capture real users’ secrets or decrypt content outside a documented authorization boundary. If you do not have a suitable lab, use an annotated packet trace and explain what would differ between the certificate-only and fully decrypted cases.
Separate SSL inspection from SSL VPN
A recurring exam-study trap is treating SSL/SSH inspection as equivalent to SSL VPN. One is a content-inspection mechanism applied to accepted sessions; the other is a remote-access feature whose behavior varies across FortiOS releases. The 7.6.0 exam is version-frozen, while SSL VPN tunnel mode was removed from later 7.6.3 operational releases. Read the legacy VPN design and migration analysis for that separate issue.
The defensible troubleshooting sequence is: determine route and firewall match, inspect the attached profile and mode, identify certificate or category evidence, then make the smallest authorized change. That is precisely the operational reasoning that the official content-inspection syllabus is designed to probe.