Hi,
my problem is with outdated certificate chains.
For example login.live.com:443 returns the following certificate chain:
0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Passport/CN=login.live.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification AuthorityIn OS X 10.11 the CA root "Class 3 Public Primary Certification Authority" certificate is being removed because OS X El Capitan will not connect to a server that allows negotiation with a 512-bit or smaller group. However there is a self signed root CA in the cert store by the same name and with the same public key as the last certificate sent in the chain "VeriSign Class 3 Public Primary Certification Authority - G5". OpenSSL's X509_V_FLAG_TRUSTED_FIRST key makes it possible not to verify the whole chain and finds out that there is already a self signed CA in the store and uses this one for verification. Same applies to different SSL stack implementation and that's why browsers for example are able to connect to the server. There's a better description in StackOverflow: http://stackoverflow.com/questions/3006 … -to-verify