On 1/9/2018 4:58 AM, Patrick Middleton wrote:
> On 09/01/2018, 03:38, "curl-library on behalf of Daniel Stenberg" <curl-library-bounces_at_cool.haxx.se on behalf of daniel_at_haxx.se> wrote:
>
> On Thu, 4 Jan 2018, Patrick Middleton wrote:
>
> > The other day one of our applications stopped working at an awkward moment,
> > reporting "result code 77, error setting certificate verify locations". We
> > have seen this error from time to time (very rarely) since 2004. It's not
> > anything to do with the file of PEM-encoded x509 certificates, the
> > certificates, or the path to the file.
>
> The most common explanation for this error message is that the site you're
> communicating with fails to present an intermediary certificate in the TLS
> handshake. You can check this by entering the site in SSL labs test:
> https://www.ssllabs.com/ssltest/ as it will clearly indicate if this is the
> fact.
>
> --
>
> / daniel.haxx.se
>
>
> That doesn't seem to be the case here. I checked the remote site's SSL installation using https://www.ssllabs.com/ssltest/ , which did not report missing intermediate certificates.
>
> We started using libcurl in 2004 in order to connect to a particular payment card processing gateway, and that's still our primary use of libcurl 14 years later. What I saw a few years back, the last time this was a significant issue, was that one of our servers was rebooted, our apps restarted, and they immediately began reporting result code 77. We restarted the apps and the issue went away. When I encountered this problem again last month, an application was running and connecting successfully, then began reporting result code 77, until the application was restarted; other applications also connecting to the same site were unaffected.
>
> I remain convinced this is a problem in OpenSSL, and it would help me to be able to get at the OpenSSL error stack.

The cafile and capath are set fairly early on [1]. We do have some ways
to access the internals such as the ctx and the resulting session but
that won't work here because of how early the error happens. I think
it's unlikely we will change to expand on this error since what you are
reporting seems very unusual. One would normally assume the cafile is
not available.

I suggest editing libcurl to grab the error yourself. For example in
that block open a FILE and call ERR_print_errors_fp to append the errors
to a file (you can't pass a FILE to OpenSSL safely in Windows, there
you'd have to use a BIO). If you instead decide to dump to a memory BIO
then you could print it as part of the failf but the libcurl error
buffer is limited to 256 characters so it may truncate the openssl error
stack.

[1]:
https://github.com/curl/curl/blob/curl-7_57_0/lib/vtls/openssl.c#L2345-L2358

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-01-12