Bug#640639: libcurl: CURLE_SSL_CACERT_BADFILE error when all CAs in ca-certificates disabled

[Simon Josefsson]

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

> On 09/06/2011 12:16 PM, Simon Josefsson wrote:
>
>>>>> | $ ls -l /etc/ssl/certs/ca-certificates.crt
>>>>> | -rw-r--r-- 1 root root 0 Sep  2 00:07 /etc/ssl/certs/ca-certificates.crt
>>>>>
>>>>> This is probably a libgnutls bug, but since I haven't pinned it down
>>>>> I'm filing it here.  Known problem?
>>>>
>>>> I recall similar problems when I also disabled all CAs on my machine
>>>> long time ago.  I suspect some software may be checking the return
>>>> code from the CA loading function, and will treat loading of 0
>>>> certificates as an error. Please try to track down the code that
>>>> triggers the error message to test this theory.
>>>
>>> I believe it isn't that simple. I think the code that returns the
>>> error in this case can be found here:
>>>
>>>     https://github.com/bagder/curl/blob/master/lib/gtls.c#L377
>>>
>>> ... and it clearly checks for a negative return value for it to be an error.
>>
>> Thanks for the pointer -- I managed to track it down, and installed a
>> patch for it:
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=ab782d356200f44736edb687304d5e90438e2185
>
> This is tricky. How do you distinguish bad pem encoding from zero
> certificates?  In any case I think that gnutls_x509_crt_list_import()
> should fail on such error, since it was always like that. The fix
> should be in gnutls_certificate_set_x509_trust_mem() and friends. I'll
> try to check it out.

Hm.  Yeah.  An alternative approach is to just check for the empty
string, or possibly whitespace, and then return zero certificates, or
otherwise return an error code.  Still, maybe it is useful for
gnutls_x509_crt_list_import to also support importing zero certificates?

/Simon