On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori <ard...@yahoo.it.invalid>
wrote:
> Hello Damjan, all,
>
> On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
>
> > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski <j...@jagunet.com> wrote:
> >
> > > I'm gonna look into the serf->(lib)curl option... Since we don't use
> any
> > > of the fancy features of serf, I'm thinking that the easy option might
> be
> > > best
> >
> >
> >
> > Hi
> >
> > I've ported our WebDAV content provider module from Serf to Curl.
>
> I just enhanced the error reporting a bit; I am finding a problem
> under Linux and I do not really know how to assess it.
>
> The problem: if we build AOO on CentOS (that is our reference
> platform) then Curl will look for CA certificates in
> /etc/pki/tls/certs/ca-bundle.crt
>
> This will fail on openSUSE and probably on Ubuntu as well.
>
> It seems that the above path is set at configure time and embedded
> into Curl's code as #define macros.
>
> Is there an ``official'' way to assess this? Like, can we depend on
> NSS' certificate store as you wrote (quoted below)?
>
Curl/OpenSSL have an enormous number of options and I am pretty sure it can
be fixed, but first I need to understand where and how it's failing.
We currently allow it to run with the default CA certificate path, do
pre-verification on the server's certificate using those CA certificates,
then call our SSL_VERIFY_PEER function where we override the verification
result with the certificates from NSS.
If it's failing before reaching our SSL_VERIFY_PEER function, we should be
able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB functions to set a
custom CA certificate path (or in-memory buffer), maybe even an empty
buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under the "SSL and
SECURITY OPTIONS" section.)
With the CURLOPT_CAINFO_BLOB option it might even be possible to skip the
custom certificate verification we do later, and pre-populate Curl/OpenSSL
with NSS certificates from the beginning, I just don't know enough about
NSS to rely on that (eg. if you are using a cryptographic device or smart
card in NSS, how does that work?). If that option is ok, then we might not
even need the NSS libraries: recent versions of NSS store all the
certificates in an SQLite database, which can be accessed with SQLite APIs
directly, no need to build with or ship the NSS libraries at all.
I am planning to write a separate email, when I get a chance, about the
cryptography libraries and certificates story.
Regards
Damjan
