An employee can open one HTTPS site while another produces a certificate warning or a web-filter block page. Both symptoms might appear immediately after a FortiGate inspection change, yet they require different explanations. A certificate-inspection policy may not see the same content as deep inspection, an endpoint may not trust the inspection authority, and a FortiGuard web category may intentionally deny access even when TLS negotiation itself works. The diagnostic task is to separate encrypted transport, certificate trust and policy classification before changing a firewall rule.

Fortinet’s NSE 4 – FortiOS 7.6 Administrator blueprint includes full SSL/SSH inspection, certificate authorities, inspection modes, web-filter profiles, FortiGuard categories, URL filters and common web-filter faults. The official FortiOS 7.6 exam outline makes these distinct tasks part of Content Inspection, its largest weighted domain. The site’s source exam code is a catalog identifier; it does not imply that a commercial practice product is official Fortinet training.

Imagine a fictional company that has just assigned deep inspection to an outbound staff policy. One laptop trusts the organization’s designated inspection CA and browses normally. Another laptop reports a certificate issuer warning, while a third shows a category-based denial for a deliberately blocked test site. Treat the three observations as different evidence rather than applying a broad bypass to every encrypted flow.

Understand what certificate inspection can and cannot establish

Certificate inspection can examine information available from the TLS setup and related connection metadata without decrypting all application payload content. It is useful for certain policies, but it cannot be treated as full visibility into the encrypted HTTP body. Deep inspection involves intercepting, inspecting and re-encrypting traffic according to the selected FortiOS profile and supported protocol behavior. The scope of available information depends on TLS version, protocol features and chosen policy.

Fortinet’s SSL & SSH Inspection reference identifies built-in profiles and documents certificate, deep and no-inspection options. The administrator must know which profile is selected by the effective firewall policy and which traffic class and protocols it covers. A web-filter denial should not automatically be called an SSL handshake error merely because the URL started with https.

FortiGate flow and proxy inspection can expose different evidence and processing constraints for the same permitted HTTPS request. First identify the active inspection mode and SSL profile; then distinguish certificate trust failure from a FortiGuard category decision or an application response. Changing a filtering category cannot repair a client that rejects the inspection certificate, and installing a trusted inspection authority cannot override a deliberate category block.

Treat the inspection CA as an explicit trust dependency

With outbound deep inspection, FortiGate can present a reissued certificate to a client during a controlled proxy interaction. The client must trust the issuing CA that the organization has authorized for that policy. A certificate warning may indicate that the endpoint lacks the relevant CA, that a chain is invalid, that hostname validation fails, or that a different security product is intercepting the connection.

Never solve a trust error by telling users to disable browser certificate checks. Instead, compare the certificate issuer and chain observed by the affected client with the approved inspection configuration, using safe diagnostics that do not export private keys. Verify the organizational CA was distributed through an authorized endpoint-management process and that the certificate’s permitted use and lifecycle are understood.

Some applications use certificate pinning or protocols that do not tolerate this inspection design. Other traffic classes may be exempt by a documented business or privacy requirement. Do not propose decryption of banking, health or other sensitive categories merely to improve visibility; review Fortinet’s capabilities and the organization’s consent, lawful-use and security policy before choosing exceptions.

Connect web-filter profiles to their active inspection modes

A web-filter profile applies policy to destinations, URLs and categories according to the available traffic visibility. Fortinet’s web-filter profile configuration documentation explains that the flow/proxy feature selection must match the associated firewall policy’s inspection mode and that SSL inspection and web filtering are selected together where applicable. A profile existing in the GUI does not prove it is attached to the traffic’s actual policy.

Suppose the company intends to deny a specific web category. A request could be blocked by the intended FortiGuard category, by a more specific URL-filter rule or by a different policy with an earlier match. Identify the actual decision source rather than immediately creating a new allow exception. Different action settings can produce block pages, warnings or monitoring events, and the observed experience will depend on browser and protocol.

FortiGuard category databases, licensing and reachability are external dependencies. If a newly registered domain is classified unexpectedly, gather the actual category and action evidence and use an approved classification-review process. Do not hard-code a broad wildcard allow rule based on a single unexplained user complaint.

Distinguish certificate errors, category denials and network failures

Start with an HTTPS URL in a controlled test environment. A browser’s explicit certificate chain error points first toward trust, hostname or TLS interception. A rendered FortiGate web-filter denial with a policy and category reference suggests policy classification. A connection timeout or reset without a certificate response may reflect routing, firewall policy, upstream service failure or protocol negotiation; the GUI wording alone is not enough.

Capture the effective firewall policy, selected SSL profile and web-filter profile, then correlate their permitted or denied action with the appropriate traffic and security-profile logs. Reproduce with one affected and one known-good client on the same test site. If only one client fails while the policy is constant, the endpoint trust store and application behavior deserve attention.

Encrypted ClientHello and newer encrypted DNS behaviors may change what a network can infer from setup metadata, depending on platform and inspection support. Fortinet 7.6 documentation includes controls for ECH-related handling. Do not assume that a new TLS mechanism bypasses all policy or that every certificate-only configuration sees the same names. Test the exact supported feature and release before making a high-confidence claim.

Keep privacy and inspection coverage in balance

Deep inspection can enable important security controls but also adds endpoint trust, resource and privacy responsibilities. Large-scale deployment should be justified by threat exposure, regulatory requirements, supported applications and lawful-use safeguards. A security team needs to know when content inspection is essential and when metadata or destination policy provides sufficient control.

Evaluate the effect on high-CPU or memory-limited FortiGate models. A policy that enables deep TLS inspection, antivirus and proxy services can consume more resources than a lighter configuration. The hardware’s capacity, actual concurrent sessions and negotiated protocols must be evaluated before any claims about performance. Reducing inspection solely to make a slow test pass might violate the approved security baseline.

Exemptions should be narrow and documented. If a pinned corporate application legitimately cannot be intercepted, record its destination, business owner, compensating controls and expiry review. A sweeping no-inspection exemption for all encrypted traffic would defeat the purpose of the policy and should not be introduced as an unexamined troubleshooting shortcut.

Design a safe three-client verification drill

In an isolated lab, configure a supported inspection profile and a designated testing CA under approved management procedures. Client A trusts the lab CA; Client B deliberately lacks that trust; Client C is authorized but requests a test URL in a deliberately denied category. Predict which of those should produce normal access, a certificate warning or a policy denial before running the experiment.

Record the observed certificate issuer, affected policy ID, SSL-profile selection, web-filter category, browser error and relevant log entries. Then repair the one intended misconfiguration and repeat the test without changing unrelated firewall policies. Avoid real customer data, personal web histories and reusable private keys in published results. This article does not claim to have run FortiOS or a TLS laboratory.

A TLS troubleshooting conclusion should name the failing layer. If a browser rejects a certificate reissued by an approved inspection proxy, check endpoint trust in the organization’s inspection CA without disabling certificate validation. If the connection negotiates TLS but the FortiGate logs a FortiGuard category denial, inspect the effective web-filter rule instead of changing the trust store. If the policy uses incompatible flow- and proxy-mode profiles, correct their attachment and retest the intended traffic; avoid a broad no-inspection exception. An independent FortiOS 7.6 inspection practice scenario is relevant when it asks which evidence distinguishes these faults and which narrow remediation follows. The practice page is third-party preparation, not Fortinet registration, and no live FortiGate test is claimed.