I downloaded Win32OpenSSL_Light-1_0_2.exe from Shining Light Productions and installed it to the default location C:\OpenSSL-Win32. I copied the file ca-bundle.crt to C:\OpenSSL-Win32\bin and ran:
C:\OpenSSL-Win32\bin>openssl s_client -connect login.live.com:443 -CAfile ca-bundle.crt
The verification of the certificate chain fails with the message:
Verify return code: 20 (unable to get local issuer certificate)
Using the same command with the same ca-bundle.crt file on Debian Wheezy with OpenSSL version 1.0.1e returns:
Verify return code: 0 (ok)
If I change the hostname to api.onedrive.com (same command) I get Verify return code: 0 (ok) on both, Windows and Linux.
Am I doing something wrong or is there a known bug? How can i get it to work on Windows for login.live.com?
(Initially I stumbled upon this problem when trying to connect to login.live.com with PHP's cURL extension under Windows XAMPP, but now it looks more like an OpenSSL issue.)
s_client has the undocumented property (or probably more a long standing bug), that if you give a -CAfile option it will not only check against the given CA file but also against the systems default (/usr/lib/ssl/certs on Debian). If you run openssl s_client with strace to check out which files are used during the verification you will see the following:
$ strace -e open openssl s_client -connect login.live.com:443 -CAfile ca-bundle.crt
...
open("ca-bundle.crt", O_RDONLY) = 3
open("/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
...
open("/usr/lib/ssl/certs/415660c1.0", O_RDONLY) = 4
open("/usr/lib/ssl/certs/415660c1.1", O_RDONLY) = 4
From this output you can see that it not only uses the given CA file for verification but also tries to use /usr/lib/ssl/cert.pem (does not exist) and then looks into /usr/lib/ssl/certs to find the required CA by the subject hash 415660c1. There it finally finds the root CA it is looking for in 415660c1.1:
$ openssl x509 -in /usr/lib/ssl/certs/415660c1.1 -text
...
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
...
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Since there are no system defaults on Windows usable by OpenSSL (it can not use the Windows CA store) the verification will fail there.
As for api.onedrive.com: this has another trust chain and can fully be verified with the given CA bundle. The output from strace shows that it does not try to access any files inside /usr/lib/ssl/certs.
