The utility's compliance team wants FortiGate to block access to a specific URL path on an otherwise-permitted HTTPS site (for example, blocking only a particular page on a general-purpose SaaS site) rather than blocking the whole domain. Which SSL inspection setting is required to make path-level filtering possible?

The HTTP request path is transmitted inside the encrypted HTTPS payload after the TLS handshake completes, so it is only visible to FortiGate if the session has been decrypted, which is what deep inspection does by terminating and re-establishing the TLS session with a substitute certificate. Certificate inspection stops at the handshake and only exposes the SNI and certificate common name, both of which identify the domain but say nothing about which specific path or page was requested afterward, so it cannot support path-level filtering no matter how the web-filter profile is configured. SD-WAN rules govern link selection and performance-based routing between WAN interfaces; they have no visibility into or control over HTTP request paths and are unrelated to this requirement. The claim that URL paths are visible in plaintext regardless of TLS is simply incorrect for properly implemented HTTPS — the entire point of TLS is to encrypt the request line and headers along with the body, which is exactly why decryption is the prerequisite here. As an operational caveat, enabling deep inspection to get path-level filtering reintroduces the certificate-substitution and pinning concerns covered elsewhere, so the compliance team should confirm this trade-off is acceptable for the specific SaaS site in question and validate the resulting web-filter logs show path-level match entries.