curl 7.38 bug fix for godaddy ca with openssl

[asaph]

When curl is built with brewed openssl, requests to any
https urls that use a cert issued by GoDaddy fail with
a curl (60) SSL certificate problem. Explicitly
specifying brewed openssl's cert bundle resolves this
issue.

Test case:

$ brew install --with-openssl curl

$ /usr/local/Cellar/curl/7.38.0/bin/curl -v https://www.godaddy.com/
* Hostname was NOT found in DNS cache
*   Trying 23.220.221.130...
* Connected to www.godaddy.com (23.220.221.130) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /usr/local/etc/openssl
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
 curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

[MikeMcQuaid]

Paging @jacknagel who has had thoughts on this in the past.

[jacknagel]

Does it not use this by default (openssl itself does)?

[asaph]

@jacknagel Apparently not. Here is a short excerpt from the ./configure command run by brew install -v --build-from-source --with--openssl curl:

  ca cert bundle:   no
  ca cert path:     no

Which brings up the following: Should homebrew pass the --with-ca-path=#{etc}/openssl/certs option to ./configure too? (when built --with-openssl) Should I add that to this pull request?

Further evidence: according to curl-config ca bundle install path is blank by default.

$ /usr/local/Cellar/curl/7.38.0/bin/curl-config --ca

(returns blank)

[DomT4]

Just to confirm this PR does solve the problem presented. Without the explicit definition of which ca path to follow curl doesn't know where to look for the ca and consequently can error out on some domains.

I'm not sure that we need to set the -ca-path though. If I leave a .pem in the top root of the OpenSSL etc directory it finds it okay. It should be semi-redundant to configure both options, although perhaps the redundancy in this case isn't a bad thing.

[jacknagel]

Does curl (built with openssl) install its own certs or something? IOW, if it only fails for some domains, it presumably is getting certs from somewhere.

I'm not opposed to this patch, I'd just like to understand it better.

[DomT4]

No, It doesn't seem to. It doesn't actually seem to explicitly specify where it looks for certs on OS X platforms built against OpenSSL rather than SecureTransport, but this is what it does in the same situation for Windows:

If you're using the curl command line tool, you can specify your own CA cert path by setting the environment variable CURL_CA_BUNDLE to the path of your choice.

If you're using the curl command line tool on Windows, curl will search for a CA cert file named "curl-ca-bundle.crt" in these directories and in this order:

    application's directory
    current working directory
    Windows System directory (e.g. C:\windows\system32)
    Windows Directory (e.g. C:\windows)
    all directories along %PATH%

So perhaps it does something like that on OS X. ❓

But I'm not sure where it would find them, given OpenSSL doesn't ship with certs by default AFAIK, and curl doesn't, and OS X doesn't keep its CA bundle inside the $PATH.

The otool for cURL with OpenSSL doesn't reveal anything particularly interesting:

Dominyks-MacBook-Pro # otool -L /usr/local/opt/curl/bin/curl                                                        [~]
/usr/local/opt/curl/bin/curl:
    /usr/local/Cellar/curl/7.38.0/lib/libcurl.4.dylib (compatibility version 8.0.0, current version 8.0.0)
    /usr/local/lib/libssh2.1.dylib (compatibility version 2.0.0, current version 2.1.0)
    /usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.4.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

[jacknagel]

Which brings up the following: Should homebrew pass the --with-ca-path=#{etc}/openssl/certs option to ./configure too? (when built --with-openssl) Should I add that to this pull request?

Just tried:

checking default CA cert bundle/path... configure: error: Can't specify both --with-ca-bundle and --with-ca-path.

[jacknagel]

I installed curl with openssl and it failed to verify every https domain I tried, so I made the commit message more generic.

[DomT4]

I wonder if it's worth throwing a caveat for brewed curl with OpenSSL pointing to cURL's upstream page on the recommended certificate bundle to use & how to obtain that.

[ghost]

+1

now git with brewed-curl works like a charm.