MacOSX-Framework: Added --without-ca-bundle to configure lines #2180
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?
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 ?