Hello Damjan,
On Sat, May 28, 2022 at 11:12:45AM +0200, Damjan Jovanovic wrote:
> On Sat, May 28, 2022 at 9:20 AM Arrigo Marchiori <ard...@yahoo.it.invalid>
> wrote:
>
> > 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.
> >
> >
> I think the problem there is NSS's validation.
>
> In CurlSession::validateServerX509Certificate(), try change the "if ( depth
> == 0 )" to "if (1)".
After this edit, the connection is established. The log is below.
But NSS was also used before, with Serf... it stopped working when the
bundled CA certificates started to be ``too obsolete''. After we
updated the bundled NSS, then https connections, such as the check for
updates, started to work again.
Please also bear in mind that I am now testing a build from a _CentOS
Docker container_. My computer is not running CentOS, but rather
OpenSUSE. The binary is run on ``native'' OpenSUSE. If I recall
correctly, when I build on the same native OpenSUSE, the resulting AOO
binary connects properly to https web sites.
For this reason, I was wondering if this problem is not just about
hardcoded paths to CA certificates.
----8<--------8<--------8<--------8<--------8<--------8<--------8<---------
1 14 2022-05-28 09:38:47.66 CurlSession::CurlSession with URL
https://ooo-updates.apache.org/aoonext/chec
k.Update?pkgfmt=installed
2 14 2022-05-28
09:38:47.66 Not using a proxy server
3 14 2022-05-28 09:38:47.66 GET line 1093
4 14 2022-05-28
09:38:47.66 [CurlINFO ] Trying 151.101.2.132:443...
5 14 2022-05-28 09:38:47.67 [CurlINFO ] Connected to
ooo-updates.apache.org (151.101.2.132) port 443 (#0)
6 14 2022-05-28 09:38:47.67 [CurlINFO ] ALPN, offering http/1.1
7 14 2022-05-28
09:38:47.67 [CurlINFO ] Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!R
C4:@STRENGTH
8 14 2022-05-28
09:38:47.67 [CurlINFO ] TLSv1.2 (OUT), TLS handshake, Client hello (1):
9 14 2022-05-28 09:38:47.68 [CurlINFO ] TLSv1.2 (IN), TLS
handshake, Server hello (2): 10 14 2022-05-28
09:38:47.68 [CurlINFO ] TLSv1.2 (IN), TLS handshake, Certificate (11):
FIXME inside OPENSSL_ValidateServerCertificate
11 14 2022-05-28
09:38:47.68 Cached certificate found with status=trusted
12 14 2022-05-28 09:38:47.68 validateServerX509Certificate()
returning 1 at depth 2 FIXME end of
OPENSSL_ValidateServerCertificate
FIXME inside OPENSSL_ValidateServerCertificate
13 14 2022-05-28
09:38:47.68 Cached certificate found with status=trusted
14 14 2022-05-28 09:38:47.68 validateServerX509Certificate()
returning 1 at depth 2 FIXME end of
OPENSSL_ValidateServerCertificate
FIXME inside OPENSSL_ValidateServerCertificate
15 14 2022-05-28 09:38:47.68 Cached certificate found with
status=trusted
16 14 2022-05-28 09:38:47.68 validateServerX509Certificate()
returning 1 at depth 1
FIXME end of OPENSSL_ValidateServerCertificate
FIXME inside OPENSSL_ValidateServerCertificate
17 14 2022-05-28 09:38:47.68 Cached certificate found with
status=trusted
18 14 2022-05-28 09:38:47.68 validateServerX509Certificate()
returning 1 at depth 0
FIXME end of OPENSSL_ValidateServerCertificate
19 14 2022-05-28 09:38:47.68 [CurlINFO ] TLSv1.2 (IN), TLS
handshake, Server key exchange (12):
20 14 2022-05-28 09:38:47.68 [CurlINFO ] TLSv1.2 (IN), TLS
handshake, Server finished (14):
21 14 2022-05-28 09:38:47.68 [CurlINFO ] TLSv1.2 (OUT), TLS
handshake, Client key exchange (16):
22 14 2022-05-28 09:38:47.68 [CurlINFO ] TLSv1.2 (OUT), TLS
change cipher, Change cipher spec (1):
23 14 2022-05-28 09:38:47.68 [CurlINFO ] TLSv1.2 (OUT), TLS
handshake, Finished (20):
24 14 2022-05-28 09:38:47.69 [CurlINFO ] TLSv1.2 (IN), TLS
change cipher, Change cipher spec (1):
25 14 2022-05-28 09:38:47.69 [CurlINFO ] TLSv1.2 (IN), TLS
handshake, Finished (20):
26 14 2022-05-28 09:38:47.69 [CurlINFO ] SSL connection using
TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
27 14 2022-05-28 09:38:47.69 [CurlINFO ] ALPN, server accepted
to use http/1.1
28 14 2022-05-28 09:38:47.69 [CurlINFO ] Server certificate:
29 14 2022-05-28 09:38:47.69 [CurlINFO ] subject:
CN=*.apache.org
30 14 2022-05-28 09:38:47.69 [CurlINFO ] start date: Apr 18
19:43:41 2022 GMT
31 14 2022-05-28 09:38:47.69 [CurlINFO ] expire date: Jul 17
19:43:40 2022 GMT
32 14 2022-05-28 09:38:47.69 [CurlINFO ] subjectAltName: host
"ooo-updates.apache.org" matched cert's "*
.apache.org"
33 14 2022-05-28 09:38:47.69 [CurlINFO ] issuer: C=US; O=Let's
Encrypt; CN=R3
34 14 2022-05-28 09:38:47.69 [CurlINFO ] SSL certificate verify
ok.
[35 and following messages are about the actual transfer ]
----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
