Bug 733792 - curl --capath does not work
Summary: curl --capath does not work
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: curl
Version: 13
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-26 21:23 UTC by JJ Keijser
Modified: 2011-09-12 11:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-12 11:32:29 UTC


Attachments (Terms of Use)

Description JJ Keijser 2011-08-26 21:23:33 UTC
Description of problem:

curl --capath <some-dir> does not work
None of the CA cerst listed in the directory are picked up by curl

Version-Release number of selected component (if applicable):
7.20.1-5.fc13

same problem occurs on fc14, rhel6

How reproducible:


Steps to Reproduce:
1. set up a secure website using a custom CA cert (i.e. not one trusted by /etc/pki/nssdb ; 
2. do a
  curl -v -3 --capath $X509_CERT_DIR <host>

  
Actual results:
* About to connect() to grasveld.nikhef.nl port 9000 (#0)
*   Trying 194.171.97.21... connected
* Connected to grasveld.nikhef.nl (194.171.97.21) port 9000 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: /home/janjust/.globus/certificates/
* Certificate is signed by an untrusted issuer: 'CN=NIKHEF medium-security certification auth,O=NIKHEF,C=NL'
* NSS error -8172
* Closing connection #0
* Peer certificate cannot be authenticated with known CA certificates
curl: (60) Peer certificate cannot be authenticated with known CA certificates
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.


Expected results:
* About to connect() to grasveld.nikhef.nl port 9000
*   Trying 194.171.97.21... connected
* Connected to grasveld.nikhef.nl (194.171.97.21) port 9000
* successfully set certificate verify locations:
*   CAfile: /user/janjust/.globus/certificates/16da7552.0
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Request CERT (13):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS handshake, CERT verify (15):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
* 	 subject: /O=dutchgrid/O=hosts/OU=nikhef.nl/CN=grasveld.nikhef.nl
* 	 start date: 2010-09-27 00:00:00 GMT
* 	 expire date: 2011-09-27 14:46:26 GMT
* 	 subjectAltName: grasveld.nikhef.nl matched
* 	 issuer: /C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: grasveld.nikhef.nl:9000
> Accept: */*
> 
< HTTP/1.1 200 OK
[...]

Additional info:

this bug was introduced when curl was compiled/linked using nss instead of openssl

Comment 1 JJ Keijser 2011-08-26 21:30:54 UTC
posted wrong "expected result"; here is the correct output:

* About to connect() to grasveld.nikhef.nl port 9000
*   Trying 194.171.97.21... connected
* Connected to grasveld.nikhef.nl (194.171.97.21) port 9000
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: /global/ices/lcg/glite3.2.8/etc/grid-security/certificates
* SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Request CERT (13):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS handshake, CERT verify (15):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
* 	 subject: /O=dutchgrid/O=hosts/OU=nikhef.nl/CN=grasveld.nikhef.nl
* 	 start date: 2010-09-27 00:00:00 GMT
* 	 expire date: 2011-09-27 14:46:26 GMT
* 	 subjectAltName: grasveld.nikhef.nl matched
* 	 issuer: /C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: grasveld.nikhef.nl:9000
> Accept: */*
> 
< HTTP/1.1 200 OK

Comment 2 Kamil Dudka 2011-08-26 23:38:25 UTC
This should be fixed in curl-7.21.3-7.fc15.  Fedora 13 is EOL:

http://fedoraproject.org/wiki/End_of_life

Comment 3 JJ Keijser 2011-09-12 08:03:07 UTC
I see it works on FC14 and on Scientific Linux 6, with one note: it seems that curl wants to read ALL files in whatever path you specify for --ca-path, whereas the openssl build of curl only reads on the .0 and .r0 files (the latter is the correct behaviour, IIRC).

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.

Comment 4 Kamil Dudka 2011-09-12 11:32:29 UTC
(In reply to comment #3)
> I see it works on FC14 and on Scientific Linux 6, with one note: it seems that
> curl wants to read ALL files in whatever path you specify for --ca-path,
> whereas the openssl build of curl only reads on the .0 and .r0 files (the
> latter is the correct behaviour, IIRC).

Yes, it goes through all files in the given directory and if it encounters a file that cannot be opened or loaded, it ignores the error.  The only problem I am aware of is that NSS leaks memory when handling those errors.  Vote for bug 734760 if you need this fixed (patch already there).

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

That should not be necessary unless you are using features that are specific to a particular SSL backend.


Note You need to log in before you can comment on or make changes to this bug.