Bug 733792

Summary: curl --capath does not work
Product: [Fedora] Fedora Reporter: JJ Keijser <jan.just.keijser>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 13CC: kdudka, paul
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-12 11:32:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.