I’m running into a TLS problem with the Seafile desktop client (AppImage version 9.0.18) on a freshly installed Kubuntu 24.04: The client refuses to connect with “Failed to establish a secure connection.” My server uses a certificate issued by HARICA (Hellenic Academic and Research Institutions CA).
What I’ve already ruled out:
The certificate itself is valid. Firefox connects to the web interface without any warning.
The same Seafile server works without issues from other Seafile clients on other devices.
curl -v https://myserver.example/api2/ping/ succeeds with no certificate error.
The system clock is correct (date, time and timezone all fine), so this isn’t a “not yet valid / expired” issue.
Based on the information provided and common issues with the Seafile client on Linux, the “Failed to establish a secure connection” error on Kubuntu 24.04—especially when curl and browsers work—is often related to how the AppImage handles SSL certificates or how the server’s certificate chain is configured.
Potential Causes and Solutions
1. Incomplete Certificate Chain
Even if Firefox and curl work, the Seafile client (which uses the Qt library for networking) can be more sensitive to missing intermediate certificates. Firefox often caches intermediate certificates from previous sites, and curl might use a different trust store.
Verification: Use an SSL checker (like SSL Labs) to confirm that your server is serving the full certificate chain, including all intermediate certificates.
Fix: Ensure your web server (Nginx/Apache) is configured to provide the full chain (usually by concatenating your certificate and the intermediate certificate into one .crt file).
2. AppImage SSL Environment
The AppImage version of Seafile sometimes has trouble locating the system’s certificate store on newer distributions like Kubuntu 24.04.
Verification: You already tried SEAFILE_SSL_CA_PATH, but the AppImage might be looking for SSL_CERT_FILE or SSL_CERT_DIR instead.
Fix: Try running the AppImage with these variables:
If the client cannot verify the CA automatically, you can bypass this check to confirm if the issue is strictly certificate verification.
Action: In the Seafile client, go to Settings > Advanced and check “Do not verify server certificate in HTTPS syncing”.
Note: This is a workaround to test connectivity and is not recommended for long-term security unless you are using a self-signed certificate.
4. OpenSSL 3.0 Compatibility
Kubuntu 24.04 uses OpenSSL 3.0, which has stricter security requirements (e.g., forbidding older legacy algorithms or shorter key lengths). If your HARICA certificate or the server’s TLS configuration uses older standards, the Seafile client (depending on how its internal Qt/OpenSSL is bundled) might reject the connection.
Action: Check your server’s TLS settings and ensure it supports TLS 1.2 or 1.3 and uses modern ciphers.
Recommended Next Step
Check your Seafile client logs for a more specific error message. You can find them at: ~/.ccnet/logs/seafile.log and ~/.ccnet/logs/applet.log
If you see an error like “The issuer certificate of a locally looked up certificate could not be found,” it strongly confirms a missing intermediate certificate in your server’s configuration.
I tried 2., but setting the two environment variables did not help.
I had a look at the logs and found:
http-tx-mgr.c(833): libcurl failed to GET ``https://XXXXXXXXXXX/seafhttp/protocol-version:`` SSL peer certificate or SSH remote key was not OK. clone-mgr.c(716): Transition clone state for 1a84b384 from [check server] to [error]: Failed to establish secure connection. Please check server SSL certificate.
The log entries confirm that the client’s internal libcurl is failing to verify the server’s identity (SSL peer certificate or SSH remote key was not OK). This typically happens even if browsers work because browsers often have their own trust stores or cache intermediate certificates that the system (or the AppImage’s bundled libraries) might not.
Since the environment variables didn’t help, here are the next steps to narrow this down:
Seafile’s sync engine (via libcurl/Qt) is very strict about the full certificate chain. If the intermediate certificate from HARICA is missing in your server configuration, the client will reject it.
Check if the output shows the full chain (Root → Intermediate → Your Cert). Alternatively, use an online tool like SSL Labs and look for “Chain issues” or “Incomplete” warnings.
I tried openssl s_client -connect XXXXXX:443 -showcerts and got the following output, which seems to be OK:
depth=2 C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA TLS RSA Root CA 2021
verify return:1
depth=1 C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1
verify return:1
depth=0 C = DE, ST = XXXXXX, O = XXXXXX, CN = XXXXXX
verify return:1
[…]
Server certificate subject=C = DE, ST = XXXXXX, O = XXXXXX, CN = XXXXXX
issuer=C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 5619 bytes and written 405 bytes
Verification: OK
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
The openssl output confirms that your server is serving the full certificate chain and that the system’s OpenSSL trusts it. Since the Seafile client (via libcurl) still fails, it indicates that the internal library in the AppImage is not using the same trust store or the HARICA root is missing from the specific bundle file you pointed it to.
Here are a few things to try:
Verify the CA Bundle Content: Ensure the HARICA root is actually present in the file you are exporting. Run:
If it’s not found, you might need to find the correct bundle file that includes it or manually add the HARICA root to a custom file and point the client to it.
Try Additional Environment Variables: Some versions of libcurl prefer CURL_CA_BUNDLE. Try running the AppImage with:
Connectivity Test: Just to be 100% sure it’s a trust issue and not a cipher/protocol mismatch (though openssl says TLS 1.3), go to Settings > Advanced in the Seafile client and temporarily check “Do not verify server certificate in HTTPS syncing”. If it connects immediately, we know for certain it’s a trust store issue.
Check logs for loading messages: Look at ~/.ccnet/logs/seafile.log again to see if there are any lines mentioning “loading CA bundle” or errors when trying to read the path you provided.
The additional environment variables did not help to establish a connection.
The client connected immediately and began syncing.
I did have a look at the log files and found a mistake!
When I configured the Seafile client for the first time, I set the server address by mistake to XXX. The certificate of the Seafile server was, however, for the domain XXY, a slight variation of XXX. I found the error in my Seafile client configuration (this was before I opened this thread) and corrected the server address to XXY, but I was still not able to connect to the server.
I followed the instructions in this thread, repeatedely, but unfortunately without success. Just now, I looked at the log files again and saw that the client was still trying to connect to XXX although I already changed the server address to XXY:
http-tx-mgr.c(833): libcurl failed to GET ``https://XXX/seafhttp/protocol-version:`` SSL peer certificate or SSH remote key was not OK. clone-mgr.c(716): Transition clone state for 1958f934 from [check server] to [error]: Failed to establish secure connection. Please check server SSL certificate.
I removed the account from the Seafile client and deleted all Seafile configuration and temporary files. I then set up my account again using XXY as the server address from the start, and now the https connection is working!
It seems that changing the server address from XXX to XXY using the GUI had no effect – although the new address XXY was shown in the GUI, the log files revealed that the client still tried in vain to connect to XXX.
Thanks again for the help! I hope this thread will be helpful to others in the future.
