On 1/9/2018 4:58 AM, Patrick Middleton wrote: > On 09/01/2018, 03:38, "curl-library on behalf of Daniel Stenberg" > <[email protected] on behalf of [email protected]> 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
