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, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 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, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6
Fixed In:
13.0.0
Opened: Aug 24, 2016 Severity: 3-Major
For PKCS#1, the SHA256 header should be: 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. However, there might also be this alternate header: 30 2f 30 0b 06 09 60 86 48 01 65 03 04 02 01 04 20, Some implementation use the alternate. According to PKCS#1, the first one is used when producing signature, but both should be accepted when verifying signatures. In BIG-IP, SSL uses the 1st header: 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, whereas crypto uses the 2nd header format for some cert verification: 30 2f 30 0b 06 09 60 86 48 01 65 03 04 02 01 04 20, which causes the inconsistent and signature verification fail.
SSL handshake fails because of certificate verification failure.
For some particular certificates, crypto uses alternative SHA prefix for verification.
None.
BIG-IP systems now also accept alternative SHA prefixes during the certificate SHA verification.