Bug 733794

CA certificates need to be loaded by --cacert.

this is not about a CA cert for the client, it's about which certs are presented to the server; when using Curl/openssl it is sufficient to supply the entire cert chain using '--cert': curl then presents this entire chain to the SSL server.

When using Curl/NSS I have to split the cert chain into a cert and the remainder, add the remaining certs to either --capath or to a stackec CA.pem file and then connect to the SSL server.

The annoying thing about this is that the behaviour of curl is now depending on how it is linked (i.e. using NSS or using OpenSSL); when scripting things using curl I now have to determine how curl is linked first.

(In reply to comment #2)
> When using Curl/NSS I have to split the cert chain into a cert and the
> remainder, add the remaining certs to either --capath or to a stackec CA.pem
> file and then connect to the SSL server.

Does it work this way for both OpenSSL and NSS?

with curl/openssl you can only get it workign if you specify
  curl --cert  <certificate chain>

similarly, with curl/nss you need to create a stacked certificate file and specify it using
  curl --cacert <all CA certs>

JJ, could you please create a self-contained test-case we can try with both OpenSSL and NSS?

hmmm I set up a test CA, sub-CA , server cert, client cert etc and then ran a simple test on all platforms; it turns out that the following worked on all platforms:
- stacking all required certs into a single file
- creating the *right* hash for all required certs in a --capath directory also works

so the options
$ curl -v --cert ./client.pem --key ./client.pem --cacert ./stacked.pem \
   https://127.0.0.1:4433 
or
$ curl -v --cert ./client.pem --key ./client.pem --capath <somedir> \
   https://127.0.0.1:4433 

work everywhere. The first time I tried this the wrong hash was created, as openssl 1 uses different hashes compared to openssl 0.9.8 ...

It's still a pity that the old method (pass a chain using --cert) can no longer be used, but at least I now have a single procedure for both curl/openssl and curl/nss.

(In reply to comment #6)
> It's still a pity that the old method (pass a chain using --cert) can no longer
> be used, but at least I now have a single procedure for both curl/openssl and
> curl/nss.

Then it is probably an OpenSSL-specific feature.  I doubt libcurl documentation guarantees something like that to work.  What about GnuTLS?  Could you please try it with curl/GnuTLS?  I do not have a testing setup myself...

I've written a testscript which can be used stand-alone; I've tested it against curl/openssl, curl/nss, curl/gnutls and curl/polarssl on FC154. See
  http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Funny_Curly_things
for details.

(In reply to comment #8)
> I've written a testscript which can be used stand-alone; I've tested it against
> curl/openssl, curl/nss, curl/gnutls and curl/polarssl on FC154. See
>   http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Funny_Curly_things
> for details.

Thank you for this research, JJ.

Elio, is this kind of certs something that we can address in libnsspem?

Just confirming that this issue is still present in Fedora 16 (curl/NSS). The work-around of presenting the rest of the chain via the --cacert option does work with the system curl (curl-7.21.7-7.fc16.x86_64). The problem with the workaround is that in the general case you really need to include all the certs from the system CA bundle as well as this option effects validating server certificates.

Is anyone looking at solutions here? The recommended use for proxy certificates in the grid community appears to be to include at least one additional certificate from the chain (the self-signing issuer) in the file; by extension one could include other non-root certificates necessary to verify back to a trusted root CA.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping