Bugs item #3439999, was opened at 2011-11-18 10:04
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3439999&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: SSL/TLS
>Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin Häcker (dwt)
>Assigned to: Daniel Stenberg (bagder)
Summary: Curl doesn't recognize certificates in PEM format in keychai

Initial Comment:
I've had the problem that I've got a ssl root certificate we used to sign our servers certificates in the keychain but since it was in the wrong format (DER) curl didn't recognize it.

Converting it to PEM and reimporting it in the keychain fixed it.

I would have really liked it if either the error message had pointed me in this direction earlier or curl would have just used that certificates, since openssl can happily eat both formats.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2011-11-18 13:30

Message:
I think this is due to how OpenSSL works. I can't spot any particular code
flow for DER...

----------------------------------------------------------------------

Comment By: Martin Häcker (dwt)
Date: 2011-11-18 11:57

Message:
I then tried to reproduce this from the command line without the keychain
being involved and got a similar error on the command line:

% curl -I https://some.ser.ver -vvv --cacert
~/Desktop/db.insideguidance.com.der
* About to connect() to some.ser.ver port 443 (#0)
* Trying some.ip... connected
* Connected to some.server (some.ip) port 443 (#0)
* error setting certificate verify locations:
  CAfile: /path/to/some.ser.ver.der
  CApath: none

* Closing connection #0
curl: (77) error setting certificate verify locations:
  CAfile: /path/to/some.ser.ver.der
  CApath: none

----------------------------------------------------------------------

Comment By: Martin Häcker (dwt)
Date: 2011-11-18 11:55

Message:
here's some output from curl that tripped me up initially:

% curl -I https://some.serv.ver -v
* About to connect() to some.serv.ver port 443 (#0)
* Trying some.ip... connected
* Connected to some.ser.ver (some.ip) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
* Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK.
Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
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.

----------------------------------------------------------------------

Comment By: Martin Häcker (dwt)
Date: 2011-11-18 10:05

Message:
% curl -V
curl 7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r
zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM SSL libz

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3439999&group_id=976
Received on 2011-11-18