[Bug]: Self-signed cert rejected

[kenwdelong]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

Title

Flatpak build 3.17.0/3.17.1: self-signed root CA rejected even when trusted in system store

---

Description

After upgrading to Nextcloud Desktop 3.17.0 (Flatpak on Pop!_OS 22.04), the client stopped accepting my self-signed root certificate.

• The root CA is installed system-wide (/usr/local/share/ca-certificates/..., updated with update-ca-certificates).
• openssl s_client -connect <server>:443 -CApath /etc/ssl/certs returns Verify return code: 0 (ok).
• But the Nextcloud client refuses to connect, logs:
• Clearing cookies0.db does not help.
• Rolling back to 3.16.3 (Flatpak) makes syncing work again.

This looks like a regression introduced in 3.17.0 around stricter certificate validation, combined with the Flatpak sandbox not using the host CA bundle.

---

Environment

• OS: Pop!_OS 22.04 (Ubuntu-based)
• Client version: 3.17.0 and 3.17.1 (Flatpak from Flathub)
• Server: Nextcloud on Start9 (self-signed CA with intermediate)
• Cert trust: Root CA installed in host trust store, verified with OpenSSL

---

Steps to reproduce

Steps to reproduce

1. Install Nextcloud Desktop 3.17.0 or 3.17.1 via Flatpak.
2. Add a server with a valid certificate chain rooted in a self-signed CA that is trusted on the host.
3. Attempt to connect.

---

Workarounds tried

• Verified root CA in host store (openssl passes).
• Cleared Flatpak client cache (cookies0.db).
• Tried exporting host CA bundle into Flatpak config and pointing SSL_CERT_FILE to it. Didn’t help.
• Downgraded to 3.16.3 → works fine again.

---

Notes

This seems related to stricter certificate checks introduced in 3.17.0. Please confirm whether this is an intentional policy change (self-signed no longer supported by default) or a Flatpak packaging issue (not picking up host CA).

Expected behavior

Expected behavior

The Flatpak client should honor the system’s trust store or allow using a user-provided CA, just as 3.16.x did.

---

Actual behavior

• Client refuses to connect, claiming “root certificate … is self-signed and untrusted.”
• Logs show “Certs not trusted by user decision.”

---

Which files are affected by this bug

certificateFile

Operating system

Linux

Which version of the operating system you are running.

PopOS

Package

Community FlatPak

Nextcloud Server version

27.1.17

Nextcloud Desktop Client version

3.17.0

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 3.16.1 to 3.16.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Additional info

No response

[Rello]

Hello,
please check here
#8654

is the server sending HSTS headers? then this is not supposed to work

[Aimmig]

Can confirm. I do not have HSTS configured and use standard packages, so I' assume this is not related to the packing format.
This bug prevents any logins that use self-signed certificates, even for already existing accounts no re-logins are possible.
The usual login-popup just doesn't show up and without knowing this is rather confusing.
Downgrading and then upgrading again did work for the moment.

[EmFl]

Hello,
I'm in a similar boat.
Nextcloud running behind reverse proxy, reverse proxy serves a *.home.arpa certificate signed by a local ca. I've added the CA in my system trust store (via trust anchor + update-ca-certificates).
Running gnutls-cli from the flatpack confirms that certificate is trusted (flatpak run --command=sh com.nextcloud.desktopclient.nextcloud)

gnutls-cli cloud.home.arpa
gnutls[2]: Enabled GnuTLS 3.8.10 logging...
gnutls[2]: getrandom random generator was selected
gnutls[2]: Intel SSSE3 was detected
gnutls[2]: Intel AES accelerator was detected
gnutls[2]: Intel GCM accelerator (AVX) was detected
gnutls[2]: cfg: unable to access: /etc/gnutls/config: 2
Processed 376 CA certificate(s).
Resolving 'cloud.home.arpa:443'...
Connecting to '192.168.20.114:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=*.home.arpa,OU=IT,O=HomeLab,L=City,ST=State,C=US', issuer `CN=Local Root CA,OU=IT,O=HomeLab,L=City,ST=State,C=US', serial 0x4c5c5ea5bc6e38bcd665c75c070719f778aed4d0, RSA key 2048 bits, signed using RSA-SHA256, activated `2025-09-18 11:54:18 UTC', expires `2027-09-18 11:54:18 UTC', pin-sha256="QwW/JnbqbRJn8D4DzPK7Y53EKAUgxYOvgILtNEQh3eI="
	Public Key ID:
		sha1:847e1902f5d8c9eeb37aead1aa4c86c3a4003c14
		sha256:4305bf2676ea6d1267f03e03ccf2bb639dc4280520c583af8082ed344421dde2
	Public Key PIN:
		pin-sha256:QwW/JnbqbRJn8D4DzPK7Y53EKAUgxYOvgILtNEQh3eI=

- Status: The certificate is trusted. 
- Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Session ID: A8:04:8F:2E:6B:29:CA:B4:92:9C:16:80:9C:6A:21:0B:1D:15:EF:A2:84:AD:92:6B:B4:86:4D:2F:31:5E:AB:B6
- Options:
- Handshake was completed

However nextcloud complains about being unable to verify it (is it the wildcard?)

/app/bin/nextcloudcmd -u emfl . https://cloud.home.arpa
Password for account with username emfl: 09-19 15:33:33:334 [ info nextcloud.sync.accessmanager ]:	2 "" "https://cloud.home.arpa/status.php" has X-Request-ID "fd6e581c-171d-4b33-a63a-fb6e0cb09386"
09-19 15:33:33:334 [ info nextcloud.sync.networkjob ]:	OCC::CheckServerJob created for "https://cloud.home.arpa" + "status.php" ""
09-19 15:33:33:341 [ info nextcloud.sync.account ]:	ssl errors "SSL-Errors happened for url  \"https://cloud.home.arpa/status.php\" \tError in  QSslCertificate(Version=\"3\", SerialNumber=\"4c:5c:5e:a5:bc:6e:38:bc:d6:65:c7:5c:07:07:19:f7:78:ae:d4:d0\", Digest=\"Ea9zQSYz24brrXkk2lYqMA==\", Issuer=\"Local Root CA\", Subject=\"*.home.arpa\", AlternativeSubjectNames=QMultiMap((QSsl::DnsEntry, \"home.arpa\")(QSsl::DnsEntry, \"*.home.arpa\")), EffectiveDate=QDateTime(2025-09-18 11:54:18.000 UTC Qt::UTC), ExpiryDate=QDateTime(2027-09-18 11:54:18.000 UTC Qt::UTC)) : \"The issuer certificate of a locally looked up certificate could not be found\" ( \"The issuer certificate of a locally looked up certificate could not be found\" ) \n \tError in  QSslCertificate(Version=\"3\", SerialNumber=\"4c:5c:5e:a5:bc:6e:38:bc:d6:65:c7:5c:07:07:19:f7:78:ae:d4:d0\", Digest=\"Ea9zQSYz24brrXkk2lYqMA==\", Issuer=\"Local Root CA\", Subject=\"*.home.arpa\", AlternativeSubjectNames=QMultiMap((QSsl::DnsEntry, \"home.arpa\")(QSsl::DnsEntry, \"*.home.arpa\")), EffectiveDate=QDateTime(2025-09-18 11:54:18.000 UTC Qt::UTC), ExpiryDate=QDateTime(2027-09-18 11:54:18.000 UTC Qt::UTC)) : \"No certificates could be verified\" ( \"No certificates could be verified\" ) \n "
09-19 15:33:33:341 [ info nextcloud.sync.account ]:	QList(QSslCertificate(Version="3", SerialNumber="4c:5c:5e:a5:bc:6e:38:bc:d6:65:c7:5c:07:07:19:f7:78:ae:d4:d0", Digest="Ea9zQSYz24brrXkk2lYqMA==", Issuer="Local Root CA", Subject="*.home.arpa", AlternativeSubjectNames=QMultiMap((QSsl::DnsEntry, "home.arpa")(QSsl::DnsEntry, "*.home.arpa")), EffectiveDate=QDateTime(2025-09-18 11:54:18.000 UTC Qt::UTC), ExpiryDate=QDateTime(2027-09-18 11:54:18.000 UTC Qt::UTC)))
09-19 15:33:33:341 [ warning nextcloud.sync.networkjob ]:	Network request error "SSL handshake failed: The issuer certificate of a locally looked up certificate could not be found" HTTP status 0 httpReason ""
09-19 15:33:33:341 [ warning nextcloud.sync.networkjob ]:	SslHandshakeFailedError:  "An unexpected error occurred. Please try syncing again or contact contact your server administrator if the issue continues."  : can be caused by a webserver wanting SSL client certificates
09-19 15:33:33:341 [ warning nextcloud.sync.networkjob ]:	Network request error "SSL handshake failed: The issuer certificate of a locally looked up certificate could not be found" HTTP status 0 httpReason ""
09-19 15:33:33:341 [ warning nextcloud.sync.networkjob ]:	QNetworkReply::SslHandshakeFailedError "An unexpected error occurred. Please try syncing again or contact contact your server administrator if the issue continues." QVariant(Invalid)
09-19 15:33:33:341 [ warning nextcloud.sync.networkjob.checkserver ]:	error: status.php replied  0 ""
Error connecting to server for status

[mgallien]

@EmFl you should test with openssl which is what we use when building the appimage package
I am unsure how openssl inside the AppImage behaves with regard to host CA specific configuration
so if you test with openssl running on your host, that may gives us some clue

[nbaak]

I am running nextcloud on my RPi in a docker compose stack behind an nginx reverse proxy. I am using a simple self signed certificate because this server will never be accessible from the internet without a vpn.

When I upgraded my nextcloud-desktop from 3.16.6 to 3.17.1 the SSL error "The host name did not match any of the valid hosts for this certificate"
like described in: https://www.reddit.com/r/NextCloud/comments/1mqr5ji/update_to_client_317_causes_ssl_certificate_errors/?tl=de

My solution for now is to downgrade back to 3.16.6

[cyrg38]

Same here after upgrading desktop client to 3.17.1 AppImage : produces errors on ssl handshaking :

...SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking...

Returning to 3.16.6 AppImage client resolves and sync again without any modification on server.

[EmFl]

Hello @mgallien
Indeed with openssl the result is KO. I get Verify return code: 20 (unable to get local issuer certificate)
Looking inside the flatpak inside /etc/ssl/cert.pem I don't see my local certificate. Outside of flatpak fs, I see it.
I'm not sure how flatpak works and if there's a way to somehow update the content of the sandbox here ?

This doesn't work (cert.pem is a symbolic link to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem):
openssl s_client -verify_return_error -connect cloud.home.arpa:443 -CAfile=/var/run/host/etc/ssl/cert.pem

This works :
openssl s_client -verify_return_error -connect cloud.home.arpa:443 -CAfile=/var/run/host/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem