Picture this: You’ve just enabled SSL inspection on your FortiGate, created an allow all rule for a trusted internal web server, and… traffic stops cold.
You double-check the firewall policy. You re-verify the certificate. Everything should be fine. But your users keep reporting errors, and your logs don’t show anything obvious.
The culprit? A FortiGate SSL inspection setting that hides in plain sight — and only shows itself under certain conditions.
This article walks through why FortiGate may reject self-signed SSL connections even when explicitly allowed, the root cause behind this behavior, and the exact steps to fix it without weakening your security posture.
FortiGate’s SSL inspection feature allows the firewall to decrypt and inspect encrypted traffic to detect threats. This process involves:
Intercepting the TLS/SSL handshake between client and server.
Validating the server’s SSL/TLS certificate.
Decrypting the traffic for inspection (full mode) or inspecting only the certificate (certificate-inspection mode).
The key part here: FortiGate must be able to probe the certificate during the handshake to decide whether to allow or block the session.
Self-signed certificates are common in:
Internal web services
Development environments
Appliances and IoT devices
Environments using certificate pinning
These certs are not issued by a public CA and can’t be validated through standard trust chains. When FortiGate can’t probe or verify a certificate — even if you’ve created an “allow” rule — it may still block the connection.
Let’s take a real example.
You enable SSL inspection, create a rule allowing traffic to your internal development server running a self-signed cert, and test from a client machine. Instead of your app loading, the browser spins and times out.
You check the CLI:
config firewall ssl-ssh-profile
edit "<your_profile_name>"
config https
show full
Output:
config https
set quic bypass
...
### No 'set cert-probe-failure' option here ###
end
That missing set cert-probe-failure line is the smoking gun.
FortiGate is silently refusing the connection because it considers an unprobed certificate to be a risk. You never even get the chance to accept or bypass it.
If your SSL inspection profile is set to Inspect All Ports, FortiGate treats all TCP traffic as potential SSL/TLS and applies generic handling rules.
The side effect? The cert-probe-failure setting — which controls whether FortiGate will allow traffic when it can’t validate the cert — doesn’t even appear in the CLI or GUI.
Think of it like a border officer saying, “If I can’t scan your passport, you’re not entering — and I won’t even tell you that’s the reason.”
When this issue occurs, your FortiGate logs might show something like:
SSL connection is blocked due to unable to retrieve the server’s certificate
Or, in the GUI, you’ll see:
Action: Deny
Service: HTTPS
Message: SSL certificate probe failed
If you’re inspecting all ports, this may happen for any traffic that FortiGate suspects is SSL — not just HTTPS on port 443.
Here’s how to make FortiGate accept self-signed certificates while keeping control over which connections get that exception.
Switch your SSL inspection profile from Inspect All Ports to only HTTPS on port 443.
CLI:
config firewall ssl-ssh-profile
edit "<your_profile_name>"
config https
set ports 443
end
next
end
Why this matters:
FortiGate now recognizes the traffic as standard HTTPS and reveals the missing cert-probe-failure option. You can’t set it when inspecting all ports.
With inspection scoped to port 443, enable the cert-probe-failure setting:
config firewall ssl-ssh-profile
edit "<your_profile_name>"
config https
set cert-probe-failure allow
end
next
end
What this does:
Tells FortiGate to permit the connection even if it can’t retrieve or validate the server’s certificate. This is safe for:
Known internal systems
Trusted external services with pinned/self-signed certs
You need to apply your updated SSL/SSH inspection profile to the firewall policy handling the traffic.
GUI:
Navigate to Policy & Objects → IPv4 Policy
Edit the policy for your traffic
Under SSL/SSH Inspection, select your updated profile
CLI:
config firewall policy
edit <policy_id>
set ssl-ssh-profile "<your_profile_name>"
next
end
Let’s break down why this fix works.
1. Proper Port Mapping
When restricted to port 443, FortiGate applies HTTPS-specific handling, allowing you to configure certificate probe behavior.
2. cert-probe-failure allow Setting
Without this, FortiGate blocks any connection where it can’t fully validate the certificate.
With it, the firewall assumes you’ve vetted the destination and lets the session proceed.
In FortiOS 7.6.0, new SSL inspection profiles default to:
set cert-probe-failure allow
This means new deployments won’t hit this exact problem.
However:
Upgraded environments keep existing settings.
Profiles using “inspect all ports” still hide the option.
Older versions still require the manual fix.
This setting should not be left open for all traffic. Follow these guidelines:
✅ Allow for:
Internal servers with self-signed certs
Appliances or applications using certificate pinning
Lab/test environments
❌ Avoid for:
Unknown internet destinations
Public web browsing
Services where certificate trust is critical
Tip: Document every exception in your change control system. This protects you during audits and security reviews.
Allowing certificate probe failures globally can introduce risks:
Man-in-the-middle attacks could use an untrusted cert
Malicious sites could bypass SSL inspection entirely
You might lose visibility into suspicious encrypted traffic
Mitigation:
Scope your profile to specific firewall policies and trusted destinations only. Consider using address groups to define approved endpoints.
Self-signed certificates are part of many IT environments, but FortiGate’s SSL inspection can block them by default — even when you’ve allowed the traffic.
The fix is simple:
Scope SSL inspection to port 443.
Enable cert-probe-failure allow.
Apply your updated profile to the correct firewall policy.
Doing this preserves security while allowing legitimate services to operate without interruption.
The key takeaway: don’t waste hours troubleshooting a block that’s really just a hidden setting away from being fixed.
If you’d like, I can also add a FortiGate CLI/GUI quick-reference table to this blog so readers can see the commands and menu paths side-by-side. That would boost both SEO and practical usability. Would you like me to add that?