Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOSX-Framework: Added --without-ca-bundle to configure lines #2180


Copy link

@sbrokenshire sbrokenshire commented Dec 17, 2017

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?

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.
Copy link

jay commented Dec 17, 2017

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 ?

Copy link
Contributor Author

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. :)

bagder added a commit that referenced this pull request May 3, 2018
... when only building with SSL backends that don't use the CA bundle
file (by default), skip the check.

Fixes #2543
Fixes #2180
@bagder bagder closed this in 082bb41 May 3, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Aug 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Successfully merging this pull request may close these issues.

None yet

2 participants