Hide Forgot
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
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
This should be fixed in curl-7.21.3-7.fc15. Fedora 13 is EOL: http://fedoraproject.org/wiki/End_of_life
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.
(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.