You are not logged in.
I run my nextcloud via dynamic IP from a fritzbox. My main domain just points via CNAME there. So my.domain.tld -> CNAME -> random.myfritz.net -> A entry.
Since a couple of days my nextcloud client has problems verifying the https certificate:
Cannot connect securely to my.domain.tld:
The host name did not match any of the valid hosts for this certificate
The certificate is self-signed, and untrusted
with Certificate random.myfritz.net
Organization: <not specified>
Unit: <not specified>
Country: <not specified>
Fingerprint (SHA-256): asdf
Fingerprint (SHA-512): asdf
Effective Date: Fri Jul 2 19:59:50 2021 GMT
Expiration Date: Fri Jan 15 19:59:50 2038 GMT
Issuer: random.myfritz.net
Organization:
Unit:
Country: I fully update ca. 1-2 per week.
There was no update of nextcloud-client since January. The problem is much newer. Looking at dependencies:
LANG=C pacman -Si nextcloud-client
Repository : extra
Name : nextcloud-client
Version : 2:3.15.3-1
Description : Nextcloud desktop client
Architecture : x86_64
URL : https://nextcloud.com/
Licenses : GPL-2.0-or-later
Groups : None
Provides : nextcloud-client-cloudproviders
Depends On : hicolor-icon-theme karchive kguiaddons libcloudproviders openssl qt6-declarative qt6-svg qt6-webengine qt6-websockets qt6-5compat
qtkeychain-qt6 sqlite xdg-utils
Optional Deps : kio: integration with Dolphin
nemo-python: integration with Nemo
nautilus-python: integration with Nautilus
python-caja: integration with Caja
Conflicts With : nextcloud-client-cloudproviders
Replaces : nextcloud-client-cloudproviders
Download Size : 4.57 MiB
Installed Size : 18.36 MiB
Packager : Caleb Maclennan <alerque@archlinux.org>
Build Date : Tue Jan 7 14:56:30 2025
Validated By : SHA-256 Sum SignatureI suspect some qt5 or qt6 network issue:
cat /var/log/pacman.log| tail -n 1300 | grep qt
[2025-02-04T20:43:57+0100] [ALPM] upgraded qt6-translations (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:12+0100] [ALPM] upgraded qt6-base (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:14+0100] [ALPM] upgraded qt6-declarative (6.8.1-3 -> 6.8.2-1)
[2025-02-04T20:44:14+0100] [ALPM] upgraded qt6-svg (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:14+0100] [ALPM] upgraded qt6-tools (6.8.1-2 -> 6.8.2-2)
[2025-02-04T20:44:53+0100] [ALPM] upgraded python-pyqt5-sip (12.16.1-2 -> 12.17.0-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt5-tools (5.15.16+kde+r3-4 -> 5.15.16+kde+r3-6)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-shadertools (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-5compat (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-multimedia-gstreamer (6.8.1-2 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-multimedia (6.8.1-2 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-positioning (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-scxml (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-speech (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-wayland (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:44:55+0100] [ALPM] upgraded qt6-webchannel (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:45:14+0100] [ALPM] upgraded qt6-webengine (6.8.1-2 -> 6.8.2-1)
[2025-02-04T20:45:14+0100] [ALPM] upgraded qt6-websockets (6.8.1-1 -> 6.8.2-1)
[2025-02-04T20:46:02+0100] [ALPM] installed kdsoap-qt6 (2.2.0-1)
[2025-02-07T19:10:38+0100] [ALPM] upgraded qt6-base (6.8.2-1 -> 6.8.2-2)
[2025-02-07T19:10:44+0100] [ALPM] upgraded qca-qt6 (2.3.9-3 -> 2.3.9-4)
[2025-02-07T19:10:59+0100] [ALPM] upgraded qca-qt5 (2.3.9-3 -> 2.3.9-4)
[2025-02-21T20:06:25+0100] [ALPM] upgraded qt6-base (6.8.2-2 -> 6.8.2-3)
[2025-02-21T20:07:24+0100] [ALPM] upgraded qt6-5compat (6.8.2-1 -> 6.8.2-2)
[2025-02-21T20:07:25+0100] [ALPM] upgraded poppler-qt6 (25.01.0-1 -> 25.02.0-2)
[2025-02-21T20:08:28+0100] [ALPM] upgraded qt5-base (5.15.16+kde+r130-3 -> 5.15.16+kde+r130-4)
[2025-02-21T20:08:28+0100] [ALPM] upgraded poppler-qt5 (25.01.0-1 -> 25.02.0-2)
[2025-02-21T20:08:32+0100] [ALPM] upgraded qt6-webengine (6.8.2-1 -> 6.8.2-3)
[2025-02-21T20:12:43+0100] [ALPM] upgraded qt5-location (5.15.16+kde+r7-3 -> 5.15.16+kde+r7-4)
[2025-02-21T20:13:01+0100] [ALPM] upgraded qt5-webengine (5.15.18-5 -> 5.15.18-6)
[2025-02-21T20:14:44+0100] [ALPM] upgraded wireshark-qt (4.4.3-1 -> 4.4.4-1)
[2025-03-02T18:25:16+0100] [ALPM] upgraded wireshark-qt (4.4.4-1 -> 4.4.5-1)Any idea which one to pick for "bisecting"?
Offline
You might have better luck looking at updates to nextcloud-client's direct dependencies. My first guess would be openssl, which was updated Feb 12. Another candidate may be qt6-webengine?
Offline
Very confusing:
I have a second machine with a almost identical setup: Arch Linux, Gnome, Systemd-Resolved. One machine has problems with CNAME, the other does not. Summary:
Laptop A: server 1
Laptop A: server 2 -> certificate validation error
Laptop B: server 3
Laptop B: server 2
Both laptops are on the same wifi. /etc/nsswitch.conf looks similar, too. Laptop B has libvirt and libvirt_guest added.
server 2 is the one with the CNAME entry. Of course both clients use the cname entry, not the random.myfritz.net.
I am also using Gnome online account for the nextcloud calendar; now a pop-up by gnome arrived with the same CNAME confusion. But only on Laptop A!
I guess this rules out any qt dependencies. This must be some strange configuration issue...
Offline
Please post a full exception trace of the error. The first thing I recommend you check is for the system that fails is to be 100% sure it's pointing to the certificate you *think* it's pointing to. Also double-check the alternate names on that certificate with:
openssl x509 -noout -text -in your_certificate.crt | grep DNS:And make sure that the hostname that the failing system is connecting to is in that list with an exact match.
Are you using wildcard certificates?
Edit: since the error signals the cert as self-signed, that must mean either it is actually self-signed, OR, perhaps the certificate chain is broken and it returns the same error for both (different) cases. If it is self-signed by design, perhaps there's a configuration difference where the system that fails isn't set up to allow self-signed certs.
Last edited by twelveeighty (Yesterday 15:56:42)
Offline
I'm on the road and only have the working laptop with me; However:
Please post a full exception trace of the error.
Hm, not sure how to get an exception trace. I copied the error message from the nextcloud-client. On stdout/err there is nothing more. The error message from Gnome Online Accounts points out the same problem.
The first thing I recommend you check is for the system that fails is to be 100% sure it's pointing to the certificate you *think* it's pointing to. Also double-check the alternate names on that certificate with:
openssl x509 -noout -text -in your_certificate.crt | grep DNS:
Well this is a simple stupid letsencrypt setup on a RPi5 (server-side). I verified the intact certificate chain:
simeon@semsnb01 ~ % openssl s_client -connect my.domain.tld:443
Connecting to 88.134.86.90
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E6
verify return:1
depth=0 CN=my.domain.tld
verify return:1
---
Certificate chain
0 s:CN=my.domain.tld
i:C=US, O=Let's Encrypt, CN=E6
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Feb 8 09:10:07 2025 GMT; NotAfter: May 9 09:10:06 2025 GMT
1 s:C=US, O=Let's Encrypt, CN=E6
i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
...When I try random.myfritz.net I get the TLS certificate of collabora.domain.tld. This is because collabora is the default host in the apache configs, and a request to random.myfritz.net is handled by that config file.
Maybe it is stupid to hide my real domain? Not sure about that. If some of you guys would try you might fail because of geoblocking.
And make sure that the hostname that the failing system is connecting to is in that list with an exact match.
[block]
/tmp/bla.crt from openssl s_client -connect random.myfritz.net
openssl x509 -noout -text -in /tmp/bla.crt | grep DNS
DNS:collabora.domain.tld
[/block]
Nothing wrong here.
Are you using wildcard certificates?
No
Edit: since the error signals the cert as self-signed, that must mean either it is actually self-signed, OR, perhaps the certificate chain is broken and it returns the same error for both (different) cases. If it is self-signed by design, perhaps there's a configuration difference where the system that fails isn't set up to allow self-signed certs.
See above.
I guess the error "self-signed" might be misleading. The chain validation might be aborted due to a domain name mismatch.
Offline
When I try random.myfritz.net I get the TLS certificate of collabora.domain.tld. This is because collabora is the default host in the apache configs, and a request to random.myfritz.net is handled by that config file.
If I read that correctly, then the TLS error is to be expected: the client is requesting "https://random.myfritz.net", which resolves to the IP of the correct server through DNS configuration, but the certificate that is returned does not have "random.myfritz.net" (verbatim) listed as an alternate name, only "collabora.domain.tld". Am I stating that correctly? Because in that case, TLS should flag that as an invalid cert for that request.
If your domain names are protected, then you should keep them censored, but if not, then it's probably better to post the actual configuration names and their matching openssl outputs. If anything, mask your public IP from post #5 (88.x.x.x.x).
Offline