Last Modified: Jun 15, 2026
Affected Product(s):
BIG-IP LTM
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
Opened: Aug 29, 2025 Severity: 3-Major
After adding an unrelated certificate to the bundle, the system constructs a longer, non-preferred certificate chain instead of the preferred shorter chain. This occurs even though the intermediate CA of the preferred chain is listed before the intermediate CA of the non-preferred chain in the bundle file
The system may present a longer or non-preferred certificate chain to TLS clients. The selected chain is still a valid chain of trust, so there is no security issue. However, clients strict about specific chain paths may experience handshake failures or certificate validation warnings
This issue occurs when all of the following conditions are met: - The certificate bundle contains two or more intermediate CA certificates with the same Subject name and same Subject Key Identifier (SKID), but signed by different issuing CAs - A new, unrelated certificate is added to the bundle, which changes the internal order in which the system evaluates certificates with matching identifiers - The leaf certificate's Authority Key Identifier (AKI) matches both intermediate certificates equally, preventing the system from distinguishing between them to select the preferred chain
Since both intermediate certificates share the same key pair (same Subject and SKID), they are functionally interchangeable — Only one is needed for chain building. Remove the duplicate/older intermediate CA from the bundle and retain only the one corresponding to the preferred chain. Avoid having multiple certificates with the same Subject and AKI/SKID in a single bundle
None