Description: LO is not able to connect to SSL secured WebDAV instances when the SSL is a self signed CA and host certificate. Starting LO from CLI brings: * STATE: INIT => CONNECT handle 0x55f33adcbb10; line 1789 (connection #-5000) * Added connection 0. The cache now contains 1 members * STATE: CONNECT => RESOLVING handle 0x55f33adcbb10; line 1835 (connection #0) * family0 == v4, family1 == v6 * Trying 192.168.0.150:443… * STATE: RESOLVING => CONNECTING handle 0x55f33adcbb10; line 1917 (connection #0) * Connected to nextcloud.home.arpa (192.168.0.150) port 443 (#0) * STATE: CONNECTING => PROTOCONNECT handle 0x55f33adcbb10; line 1980 (connection #0) * GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0 * ALPN, offering h2 * ALPN, offering http/1.1 * Didn’t find Session ID in cache for host HTTPS://nextcloud.home.arpa:443 * STATE: PROTOCONNECT => PROTOCONNECTING handle 0x55f33adcbb10; line 2000 (connection #0) * SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384 * server certificate verification failed. CAfile: none CRLfile: none * multi_done * The cache now contains 0 members * Closing connection 0 * Expire cleared (transfer 0x55f33adcbb10) using WebDAV over http works fine. WebDAV config: Host: nextcloud.home.arpa Port: 443 Secure connection: checked Label: WebDAV Root: /remote.php/dav/files/ Steps to Reproduce: 1. generate a CA and a self signed wildcard certificate 2. deploy SSL cert on nextcloud and import the CA as trusted in linux (or windows, makes no differnce) 3. add WebDAV remote connection to SSL enabled nextcloud instance Actual Results: Error Message: Could not establish internet connection to nextcloud.home.arpa Expected Results: Let me connect to nextcloud with WebDAV Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.3 / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 16; OS: Linux 5.16; UI render: default; VCL: gtk3 Locale: de-AT (de_AT.UTF-8); UI: en-US Flatpak Calc: threaded
@Michael Stahl, I thought you might be interested in this issue
it should work to use the operating system's UI to add the CA certificate as trusted. i'm not sure how this works on Linux though, there is a wide variety of possibilities to build LO with bundled curl or system curl using different TLS libraries. ... apparently you are using FlatPak build? perhaps Stephan can find out if it's possible to add a trusted CA certificate so that it can find it.
I already added the root CA in the OS, in KDE you can do this by adding the crt file in System Settings -> Network -> Settings -> SSL Preferences. But it looks like this only adds the cert under "User-added certificates" - which apparently does not work or is not read by LO. Doing the cp xxx.crt /etc/ca-certificates/trust-source/anchors/ && update-ca-trust way as root works. Same behaviour in 7.3.0.3 as in 7.2.5 >... apparently you are using FlatPak build? Used, flatpak version was newer than the official/community version but seems like that changed. Switched to extra/libreoffice-fresh-7.3.0-5 now.
(In reply to gw from comment #3) > >... apparently you are using FlatPak build? > > Used, flatpak version was newer than the official/community version but > seems like that changed. Switched to extra/libreoffice-fresh-7.3.0-5 now. So, just to clarify, the issue you describe is not specific to flatpak'ed LibreOffice?
apparently LibreOfficeFlatpak.conf builds with system curl, OpenSSL and NSS. this is an interesting bug: https://github.com/flatpak/flatpak/issues/2721 apparently the idea is Flatpak app accesses host certs via "p11-kit", which communicates from app sandbox to host via socket, using "p11-kit-client.so" in the Freedesktop runtime. claims the system curl in the freedesktop-sdk doesn't work because it is built with --with-ca-bundle - that overrides any usage of "p11-kit". "trust list" shows CAs trusted by p11-kit on the host. so much for Flatpak case ... it's not clear how this should work for TDF rpm/deb builds - these currently bundle curl and NSS and NSS is not configured to use p11-kit... but it should be using some Mozilla FF/TB profile directory in "nsscrypto_initialize" function. i guess one option would be to use system NSS which should get us benefit of automatic p11-kit usage - but not clear if that works with passing explicit profile directory.
(In reply to gw from comment #3) > Used, flatpak version was newer than the official/community version but > seems like that changed. Switched to extra/libreoffice-fresh-7.3.0-5 now. i'm assuming this LO is packaged by/for Arch Linux and uses system libcurl.
okay so i did some testing... i've installed a custom CA certificate on Fedora 35 by copying it to /etc/pki/ca-trust/source/anchors/ and running sudo update-ca-trust extract my master build, when configured --without-system-nss, will not find this CA cert, but when configured --with-system-nss, it will find it and connection works fine. probably the system NSS has some p11-kit integration or other magic that is missing in the bundled NSS. but that simply means, since there's no reason to bundle NSS, we can just switch TDF builds to use system NSS and this should work. the following command also works to trust the certificate as root: sudo trust anchor --store ca-certificate.pem (not clear where the file is copied to) the Gnome "Seahorse" application ("Password and Keys") is able to display the certificate, but i can't figure out how to add it (.pem file) as trusted. --- well a CLI way to add it as root should be good enough for now; UI would be "nice to have", so i'm calling it fixed for the TDF rpm/deb builds: commit 0028266e34a683b1650410cee65dac502e304c9f Author: Michael Stahl <michael.stahl@allotropia.de> AuthorDate: Thu Aug 12 13:04:54 2021 +0200 Commit: Michael Stahl <michael.stahl@allotropia.de> CommitDate: Fri Apr 29 20:24:58 2022 +0200 configure: default to --with-system-nss on Linux --- for the Flatpak build, it would be possible to bundle curl with LO, to avoid the wrongly configured curl in the runtime, since the p11-kit infrastructure is claimed to exist in the above linked bug report.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/0e784a933ae46a938ab47bd91ddb679b66237f3c tdf#147250 configure: default to --with-system-nss on Linux It will be available in 7.3.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael, why the fix was only for 7.3? And should we close this one as FIXED?
Let's only switch status to NEEDINFO if it can't be reproduced, and needs further details from the reporter. But indeed, the 7.4.0 commit didn't have the bug number in the comment message: https://cgit.freedesktop.org/libreoffice/core/commit/?id=0028266e34a683b1650410cee65dac502e304c9f author Michael Stahl <michael.stahl@allotropia.de> 2021-08-12 13:04:54 +0200 committer Michael Stahl <michael.stahl@allotropia.de> 2022-04-29 20:24:58 +0200 configure: default to --with-system-nss on Linux
I can confirm the fix works for Version: 7.3.4.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.utf8); UI: de-DE 7.3.4-2 Calc: threaded On Windows the problem is the same. It is not possible to open documents from https sites, whether they are links or webdav, if the site is secured per internal ca. Of course the ca certificate is imported in windows certificate manager.
lets have a separate bug per OS - this one is for Linux, 149921 is for Windows
If I understand correctly, this can be considered fixed.
reading the recent comments in https://github.com/flatpak/flatpak/issues/2721 i get the impression it should be fixed if LO Flatpak uses the current freedesktop runtime.
(In reply to Michael Stahl (allotropia) from comment #14) > reading the recent comments in > https://github.com/flatpak/flatpak/issues/2721 i get the impression it > should be fixed if LO Flatpak uses the current freedesktop runtime. (latest LO 7.5.0.3 on Flathub uses org.freedesktop.Platform//22.08)