Hello Damjan, all,
On Fri, May 27, 2022 at 11:27:11PM +0200, Arrigo Marchiori wrote:
> Hello,
>
> On Fri, May 27, 2022 at 09:46:51PM +0200, Arrigo Marchiori wrote:
>
> > Hello Damjan,
> >
> > On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic wrote:
> >
> > > 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.
> >
> > Apparently, it is failing before calling our SSL_VERIFY_PEER function.
> >
> > > 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.)
> >
> > So we would need to hard-code and try all possible paths to the CA
> > bundle on Unix systems?
> >
> > > 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.
> >
> > If I understood correctly [1], a NSS-linked Curl would query NSS by
> > itself... are we not in this condition?
[...]
> 1: https://curl.se/libcurl/c/CURLOPT_CAINFO.html
Apparently, we are not. If we force CURLOPT_CAINFO and CURLOPT_CAPATH
to be NULL, we get a bit further but eventually Curl aborts because
validateServerX509Certificate fails.
Here is the log for checking AOO updates (please excuse the long
lines). I added an extra bit of logging when entering and leaving
OPENSSL_ValidateServerCertificate, that is ``our SSL_VERIFY_PEER
function''.
----8<--------8<--------8<--------8<--------8<--------8<--------8<---------
1 9 2022-05-28 07:13:52.61 CurlSession::CurlSession with URL
https://ooo-updates.apache.org/aoonext/check.Update?pkgfmt=installed
2 9 2022-05-28 07:13:52.61 Not using a proxy server
3 9 2022-05-28 07:13:52.61 GET line 1093
4 9 2022-05-28 07:13:52.61 [CurlINFO ] Trying
151.101.2.132:443...
5 9 2022-05-28 07:13:52.63 [CurlINFO ] Connected to
ooo-updates.apache.org (151.101.2.132) port 443 (#0)
6 9 2022-05-28 07:13:52.63 [CurlINFO ] ALPN, offering http/1.1
7 9 2022-05-28 07:13:52.63 [CurlINFO ] Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
8 9 2022-05-28 07:13:52.63 [CurlINFO ] TLSv1.2 (OUT), TLS
handshake, Client hello (1):
9 9 2022-05-28 07:13:52.64 [CurlINFO ] TLSv1.2 (IN), TLS
handshake, Server hello (2):
10 9 2022-05-28 07:13:52.64 [CurlINFO ] TLSv1.2 (IN), TLS
handshake, Certificate (11):
--here we are inside OPENSSL_ValidateServerCertificate
11 9 2022-05-28 07:13:52.64 validateServerX509Certificate()
returning 0 at depth 2
--here we are leaving OPENSSL_ValidateServerCertificate
12 9 2022-05-28 07:13:52.64 [CurlINFO ] TLSv1.2 (OUT), TLS
alert, unknown CA (560):
13 9 2022-05-28 07:13:52.64 [CurlINFO ] SSL certificate
problem: unable to get local issuer certificate
14 9 2022-05-28 07:13:52.64 [CurlINFO ] Closing connection 0
15 9 2022-05-28 07:13:52.64 Curl request failed with CURLcode 60
16 9 2022-05-28 07:13:52.64 CurlSession::~CurlSession: closed
curl session
----8<--------8<--------8<--------8<--------8<--------8<--------8<---------
I hope this helps.
Best regards,
--
Arrigo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
