On Fri, 17 Oct 2003, Georg Horn wrote:

> I looked at the code and modified it a little bit, so that it prints out
> the errormessage generated by openssl:

[snip]

This is a clever fix, and I'll make sure this change is applied. Thanks!

> $ src/curl --cert /tmp/mgb2003.pem -k
> https://www2.postbank-banking.de/xmlapi/OB
> Enter PEM pass phrase:
> curl: (56) SSL read: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1
> alert unknown ca, errno 0

Isn't this too identifying a bug? I mean, if we use -k we want to ignore the
status of the server's certficate and thís doesn't, right?

> I think i have the special case here, where the server renegotiates the
> connection after the request ist sent, beacuse it requires a client
> certificate only if certain URLs are requested, So this was no bug in curl,
> curl was just not revealing what really went wrong, but a problem with my ca
> certificates. It tourned out that the root certificates where missing. After
> adding my ca-certificates to curls ca-bundle.crt and using that file with
> --cacert it all works, but maybe the following things could be useful for a
> future curl-release?
>
> - apply the above patch?

Yes!

> - make curl able to continue with a warning even if certificate verification
> fails, like "openssl s_client" does? (My tries with s_client didn't really
> work, it always said "Verify return code: 19 (self signed certificate in
> certificate chain)" and continued anyway, but now it says "Verify return
> code: 0 (ok)"

That would be cool and would indeed fit when -k is used. Do you think you can
work on a patch doing this as you can repeat the situation nicely?

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com