MacOSX-Framework: Added --without-ca-bundle to configure lines #2180
Conversation
Adding --without-ca-bundle to the configure lines in the MacOSX-Framework script brings the functionality of what to do with a self-signed certificate that has been trusted in a keychain (e.g. login or System) into line with the curl installation that comes with macOS does which is not to look at /etc/ssl/cert.pem based on the curl_config.h generated in curl-95.70.1 (10.12) on the Apple Open Source website. Before adding --without-ca-bundle, running ./MacOSX-Framework and testing with 'curl https://<trusted self signed domain>' in the src directory returned error message 'curl: (51) SSL: certificate verification failed (result: 5)'. Error code 5 is kSecTrustResultRecoverableTrustFailure which shouldn't be happening if it is looking at the keychain(s) properly and a trusted self-signed certificate is there. Tested on macOS Sierra using the included installation (7.54.0) and latest development build (7.58.0-DEV) at commit 9c6a6be.
|
This is part of a larger problem. We will face the same issue when ca bundle support is added to libcurl w/ WinSSL. Also the ca bundle may be set if multiple backends are specified. For example if you built with both DarwinSSL/SecureTransport and BoringSSL enabled then should the curl tool be setting CURLOPT_CAINFO with the certificate bundle? In the case of BoringSSL I'd assume so but DarwinSSL it would make more sense to use the native certificate store. I can't think of a good way to address that, maybe a new option like CURLOPT_IF_CERT_STORE_AVAIL_THEN_IGNORE_CAINFO. The name needs work. edit: CURLOPT_USE_CA_CERT_STORE ? |
|
I like the CURLOPT_USE_CA_CERT_STORE option name. Clearly tells me that libcurl should use the native certificate store over the other backends that use the CA bundle. :) |
When I'm using my own libcurl built with the MacOSX-Framework script in my applications I've found that in Sierra at least, the included libcurl installation is configured with --without-ca-bundle while a framework produced from MacOSX-Framework doesn't.
Because of that, it is producing different results (cURL error code 51, SSL code 5) instead of outputting page data when attempting to connect to a server with a self-signed certificate that is already trusted in a keychain because it's looking in /etc/ssl/cert.pem instead of the keychains. Looking at /etc/ssl/cert.pem seems to be a really bad idea as certain valid certificates in the System Roots keychain are not appearing in the file (Sierra at least) which should be like the Deutsche Telekom, Certum and Visa ones for example.
The pull request is simply adding --without-ca-bundle to the configure lines in the MacOSX-Framework script so that it looks at the keychains instead of /etc/ssl/cert.pem.
Potential problem is issue #2103 - Apple has swapped SecureTransport for BoringSSL in High Sierra - based on this I'll test it on High Sierra and update this part of the pull request message.
I'm assuming that MacOSX-Framework should still be using SecureTransport?