Skip to main content
I_Omel
Staff
Staff
February 10, 2026

Troubleshooting Tip: SSL certificate inspection not blocking sessions with expired certificates

  • February 10, 2026
  • 0 replies
  • 513 views
Description This article describes how to handle an issue where SSL certificate inspection does not block sessions with expired certificates. 
Scope FortiGate.
Solution

In some scenarios, the configuration of Common Options in the SSL/SSH Inspection profile does not guarantee certificate expiration date, revocation, or other parameters.

 

For testing purposes, use the following URL: https://expired.badssl.com.

 

Despite how the feature has been enabled in the GUI:

 

SSL_profile.png

 

For troubleshooting, enable IPS debugging on the device. This level of debugging is typically used when comprehensive details are needed to troubleshoot complex SSL issues. It can generate a large amount of output, so it should be used with caution, especially in production environments. It is highly recommended to enable the debug commands with source/destination/port filters.

 

To filter the traffic, use the command below:

 

diagnose ips filter set
bpf filter bpf filter

 

This filter is a Berkeley filter, which allows the use of many parameters such as source, destination, and TCP/UDP ports.

Example : 

Filter the traffic from source IP 1.1.1.1 and TCP port 443:

 

diagnose ips filter set 'src 1.1.1.1 and tcp port 443'

 

Verify the filter with the following command:

 

diagnose ips filter status

DEBUG FILTER:
debug level: 17179868671
filter: "host 1.1.1.1 and tcp port 443"
process id: 0

 

To troubleshoot the issue, enable the debugging as in the example below ; 

 

     diagnose debug reset 

   diagnose debug console timestamp enable

     diagnose ips  filter set 'host x.x.x.x'

diagnose ips debug enable all

diagnose ips debug status show

diagnose ips ssl debug noise

diagnose debug enable

[2172@8]ips_transit_tcp_state: (C:SYN_SENT S:LISTEN) -- SYN ->
[2172@8]ips_handle_tcp_action: (C:SYN_SENT S:SYN_RCVD) act=FIRST_CLIENT_PKT
[2172@8]ips_l7_dsct_processor: serial=17144628 create: http
[2172@8]ips_l7_dsct_processor: serial=17144628 create: ssl
[2172@8]ips_l7_dsct_processor: serial=17144628 create: http2
[2172@8]ips_dsct_session_loop: serial=17144628 run: http
[2172@8]ips_dsct_session_loop: serial=17144628 run: ssl
[2172@8]create_run_mode: SSL CA name: Fortinet_CA_SSL, untrust CA name: Fortinet_CA_Untrusted, VDOM: 0, enable: 0, mode: 2, verifyca: 1, cert action: untrusted: 0, expired: 1, revoked: 1timeout: 1,

failure: 1, whitelist: 0

 

The result of the validation is PASS:

 

[2172@8]ips_asm_set_seq: set asm seq: 07a8e573
[2172@8]ips_dsct_session_loop: serial=17144628 run: http2
[2172@8]ips_process_event: ctx 0: 0 => 3
[2172@8]ips_handle_pkt_verdict: pass a packet, size=60

 

This is expected behavior. Common Options are only validated by the IPS engine for policies in proxy mode or for Full SSL Inspection mode.