Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2
Fixed In:
13.0.0, 12.1.2 HF1, 11.6.3.3
Opened: Mar 31, 2016 Severity: 3-Major Related Article:
K34343741
When a SSL connection with specified server name is received in a virtual server from the client side, the BIG-IP system selects one clientssl profile for this connection based on the given server name. Currently the system matches the server name using the following rules: (1) First try to match the server name with explicit server name configuration of the clientssl profiles. (2) If (1) has no match, then try to match the common names of the certificates used by the clientssl profiles. (3) If (2) has no match, then try to match the subject alternative names of the certificates used by the clientssl profiles. The issue is, based on RFC6125, common name should be used as a 'last resort'. In other words, the third rule should be the second rule.
The virtual server might select a clientssl profile that is not preferred by the client side.
The issue occurs when all of the following conditions are met. (1) The incoming SSL request includes SNI (server name) extension in the clienthello, used to specify its desirable SSL server. (2) The given server name from the client side does not match any server name configured in all the clientssl profiles of the virtual server. (3) The certificates used by the clientssl profile of the virtual server have subject alternative names (note that every certificate has common name but not necessarily subject alternative names).
None.
Priority order of clientssl profile selection of virtual server. The system now matches the server name using the following rules: (1) First try to match the server name with explicit server name configuration of the clientssl profiles. (2) If (1) has no match, then try to match the subject alternative names of the certificates used by the clientssl profiles. (3) If (2) has no match, then try to match the common names of the certificates used by the clientssl profiles. So the common-name match is last, which is correct according to RFC6125.
If server-name is not configured in the client SSL profile for SNI (server name) matching, SANs (subject alternative names) in the certificate will take precedence over CN (common name) in the certificate, for the SNI-matching process for client SSL profile selection.