Bug ID 2340941: SSL Connections Fail On Some TMMs After Concurrent CRL File Updates Across DSC Members

Last Modified: Jun 19, 2026

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3, 17.1.3.1, 17.1.3.2, 17.5.0, 17.5.1, 17.5.1.2, 17.5.1.3, 17.5.1.4, 17.5.1.5, 17.5.1.6, 21.0.0, 21.0.0.1

Opened: Jun 18, 2026

Severity: 3-Major

Symptoms

When the bug is triggered, the following symptoms are observed: - Specific TMMs begin sending FIN+ACK immediately after completing the TCP 3-way handshake, causing SSL connections to fail silently from the client's perspective - The failure is permanent and per-TMM — only the TMMs that encountered the race condition are affected; other TMMs continue to function normally - The following log messages appear in /var/log/ltm: 01260027:2: Profile <name> - cannot load CRL <path>: Unknown error. 01260000:2: Profile <name>: could not load CRL - For every connection that fails, a log similar to the following appears in /var/log/ltm for the TMM that handled the connection: 01260009:4: Connection error: hud_ssl_handler:1316: alert(40) invalid profile unknown - The condition does not automatically recover — it persists indefinitely until an administrator manually detaches and then re-attaches the affected SSL profile from the virtual server

Impact

SSL connections to the affected virtual server fail. BIG-IP closes the connection with a FIN immediately after a TCP handshake completes on affected TMMs

Conditions

All of the following must be present to trigger the bug: - Two or more BIG-IP devices in a DSC (Device Service Cluster) with automatic ConfigSync enabled - A Client SSL profile with a crl-file attached to a virtual server - Concurrent CRL file updates on both devices (e.g., both devices updating the same CRL object within the same second), causing filestore version churn

Workaround

Avoid performing simultaneous CRL file updates on both DSC members Since there is no automatic recovery from this condition, the administrator must manually detach (temporarily replace with another SSL profile) and then re-attach the intended Client SSL profile on the affected virtual server to clear the invalid profile state

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips