Since v 7.18.0 (see http://curl.haxx.se/docs/sslcerts.html), cURL does not include its own ca-certificate bundle, so you have to supply it with one. However, if I'm reading it correctly, the current ebuild for cURL only points at the shared certificate bundle in /etc/ssl/certs/ca-certificates.crt if the 'gnutls' or 'nss' USE flags are set, even if the 'ssl' USE flag *is* set. This means that no SSL connections will work without manually specifying this path at runtime, since cURL will look for a file called "curl-ca-bundle.crt" in the configured directory (/etc/ssl/certs/). I was able to work around this by creating a symlink, but can't see why this was not handled better by the ebuild: ln -s /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/curl-ca-bundle.crt update-ca-certificates Apologies if there is a good reason for this behaviour, and thanks in advance for your time. Reproducible: Always Steps to Reproduce:
Steps to reproduce: curl -v https://members.dyndns.org (error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed) curl --cacert /etc/ssl/certs/ca-certificates.crt -v https://members.dyndns.org (result OK)
Actually ebuild provides --with-ca-path that should work. Could you try curl-7.21.1, it looks like it fixed similar problem here...
Created attachment 251817 [details, diff] Proposed fix to ebuild logic --with-ca-path simply tells cURL to look in /etc/ssl/certs/ for the file "curl-ca-bundle.crt"; however, no file of this name exists on a standard Gentoo system. This is why I was able to work around the issue on a production server by creating a symlink at this location. I lack the knowledge of the ebuild system to verify or test the change, but looking at the ebuild file [1] I believe this patch would resolve the issue. Essentially, it says that if *any* flavour of SSL is enabled, point cURL to the standard certificate bundle in /etc/ssl/certs/ca-certificates.crt [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/curl/curl-7.21.1.ebuild?revision=1.1
(In reply to comment #3) > Created an attachment (id=251817) [details] > Proposed fix to ebuild logic > > --with-ca-path simply tells cURL to look in /etc/ssl/certs/ Yup. It tells the name of directory with certificates. Check manual page for SSL_CTX_load_verify_locations - it has CApath parametr that works in this case. > however, no file of this name exists on a standard Gentoo system. This is directory and that is correct. Again could you try 7.21.1? It works for me without changes. I suppose this is bug in curl 7.20.0-r2 and I'd like some confirmation on that :)
(In reply to comment #4) > Yup. It tells the name of directory with certificates. Check manual page for > SSL_CTX_load_verify_locations - it has CApath parametr that works in this case. OK, that makes sense. The observed behaviour was that cURL was using that directory only to look for a particular named file, i.e. /etc/ssl/certs/curl-ca-bundle.crt I guess this is/was the bug, and it should actually be picking up other files from that directory automatically. > Again could you try 7.21.1? It works for me without changes. I suppose this is > bug in curl 7.20.0-r2 and I'd like some confirmation on that :) OK, I can confirm that it does seem to work with the 7.21.1 version, presumably because it is using the --with-ca-path correctly. Apologies for my misunderstanding of this parameter. Any idea of how safe that version is and/or when it is likely to be marked stable?
Dror, look you were the last to touch this package. What do you think about adding patch for bug #337506 and stabilizing it? Could you do this? :)
Cannot reproduce this with 7.21.7, so I guess this is indeed fixed.
