Issue with SalesForce Cert. ---------------------------
The Salesforce cert is dumped below with linenumbers in text using "openssl x509 -text -noout | nl" for convenience.
Line 38-41 show the Authority Key Identifier - this is used to identify the public key used to sign this cert (which in practice disambiguates two potential issuing certificates with the same subject id, but different keys.)
This can be done in two separate ways
(a) using a "keyid" to specify the key itself, matching a "subject key" in the issuer's cert
(b) using a serial number and issuer name.
(Note in the second case, that's the issuer's issuer, not the subject's issuer, and for a self-signed cert, the subject, issuer, and issuer's issuer are all the same cert.)
Lines 38-41 therefore give two distinct ways to locate the issuing certificate. It's either
(a) one with subject key Id A6:E0:FA:0A:4B:47:F5:E0:7F:69:BA:E3:62:5E:D7:17:FB:B4:D5:59
(b) one with serial:01:3E:54:E9:2C:EE:00:00:00:00:5A:A5:E1:D7 and issuer /CN=BT Consumer Complaints/OU=00DW0000003idkb/ O=Salesforce.com/L=San Francisco/ST=CA/C=USA
Look at the serial number of the subject cert: 01:3e:54:e9:2c:ca:00:00:00:00:5a:a5:e1:d7
This is actually _not_ the same as the subject key Id in the subject cert (the 6th octet differs - "CA" vs "EE"), so by that definition, the key used to sign this certificate is not the same as the subject's own key, certificate, and it is not a self-signed cert. This issue causes the OpenSSL stack to fail, and reasonably so.
It's done this since 2006, at least: If another product is using OpenSSL, and is _not_ failing this verification of such a problematic salesforce cert, then it may not be verifying peer certificates properly at all (eg, by installing a handler with SSL_CTX_set_cert_verify_callback() that does not properly verify the cert chain, or calling SSL_CTX_set_verify() with SSL_VERIFY_NONE)
Issue with SalesForce Cert. ---------------------------
The Salesforce cert is dumped below with linenumbers in text using "openssl x509 -text -noout | nl" for convenience.
Line 38-41 show the Authority Key Identifier - this is used to identify the public key used to sign this cert (which in practice disambiguates two potential issuing certificates with the same subject id, but different keys.)
This can be done in two separate ways
(a) using a "keyid" to specify the key itself, matching a "subject key" in the issuer's cert
(b) using a serial number and issuer name.
(Note in the second case, that's the issuer's issuer, not the subject's issuer, and for a self-signed cert, the subject, issuer, and issuer's issuer are all the same cert.)
Lines 38-41 therefore give two distinct ways to locate the issuing certificate. It's either
(a) one with subject key Id A6:E0:FA:0A:4B:47:F5:E0:7F:69:BA:E3:62:5E:D7:17:FB:B4:D5:59
(b) one with serial:01:3E:54:E9:2C:EE:00:00:00:00:5A:A5:E1:D7 and issuer /CN=BT Consumer Complaints/OU=00DW0000003idkb/ O=Salesforce.com/L=San Francisco/ST=CA/C=USA
Look at the serial number of the subject cert: 01:3e:54:e9:2c:ca:00:00:00:00:5a:a5:e1:d7
This is actually _not_ the same as the subject key Id in the subject cert (the 6th octet differs - "CA" vs "EE"), so by that definition, the key used to sign this certificate is not the same as the subject's own key, certificate, and it is not a self-signed cert. This issue causes the OpenSSL stack to fail, and reasonably so.
It's done this since 2006, at least: If another product is using OpenSSL, and is _not_ failing this verification of such a problematic salesforce cert, then it may not be verifying peer certificates properly at all (eg, by installing a handler with SSL_CTX_set_cert_verify_callback() that does not properly verify the cert chain, or calling SSL_CTX_set_verify() with SSL_VERIFY_NONE)
