Thank you for your attention

I'm not sure it is a curl problem , maybe the openssl does. I never read any source code of them.

Just point it out.

Problem is
I don't understand why curl read Equifax_Secure_CA.pem to verify my server certificate.
I think it should be 2c543cd1.0 (soft link of /etc/ssl/certs/GeoTrust_Global_CA.pem) which is the right CA of my certificate.


Problem further is the wrong CA works but the right CA not.

    curl --cacert /etc/ssl/certs/GeoTrust_Global_CA.pem --capath none https://xxx

this will work in any other test context, but return "certificate verify failed" in ubuntu.


If I'm wrong , would you please share some references to help me understand how to perform a certificate verification.

---
** [bugs:#1418] curl choose the wrong CA certificate to verify server certificate.**
**Status:** pending-invalid
**Labels:** SSL certificate 
**Created:** Thu Aug 28, 2014 10:39 AM UTC by xelz
**Last Updated:** Thu Aug 28, 2014 11:39 AM UTC
**Owner:** Daniel Stenberg
ubuntu 12.04
curl 7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

curl choose the wrong CA certificate to verify server certificate. but unexpectedly it verify successfully.

when I sepecify the right A certificate with option cacert, it reports an error 

> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

example:
my website server certificate is issued by GeoTrust SSL CA G2 which is under GeoTrust Global CA

    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ curl --cacert /etc/ssl/certs/GeoTrust_Global_CA.pem --capath / https://xxx 2>&1 | grep error
    error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ curl --cacert GeoTrust_SSL_CA_G2.pem --capath / https://xxx 2>&1 | grep error
    error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

when I use the bundled ca certs, and trace which CA certificate file it used to verify peer

    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ strace -f -o trace.txt -- curl https://xxx && echo && grep /etc/ssl trace.txt
    #xxx verify succeed and this line is the http response
    8458  stat64("/etc/ssl/certs/578d5c04.0", {st_mode=S_IFREG|0644, st_size=1143, ...}) = 0
    8458  open("/etc/ssl/certs/578d5c04.0", O_RDONLY|O_LARGEFILE) = 4
    8458  stat64("/etc/ssl/certs/578d5c04.1", 0xbf850db0) = -1 ENOENT (No such file or directory)

who the hell ‘578d5c04.0’ is?

    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ ll /etc/ssl/certs/578d5c04.0
    lrwxrwxrwx 1 root root 21 Jun 27 12:32 /etc/ssl/certs/578d5c04.0 -> Equifax_Secure_CA.pem

I'm sure that neither issuer_hash of my server certificate chain is 578d5c04

    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ openssl x509 -hash -issuer_hash -noout -in  myserver.pem
    e9b72057
    322109c8
    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ openssl x509 -hash -issuer_hash -noout -in  /etc/ssl/certs/GeoTrust_SSL_CA_G2.pem
    322109c8
    2c543cd1
    xelz_at_ubuntu: /tmp/certs [18:06:59]
    $ openssl x509 -hash -issuer_hash -noout -in  /etc/ssl/certs/GeoTrust_Global_CA.pem
    2c543cd1
    2c543cd1
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.