Fix “SSL Certificate Verification Failed” in the ownCloud Desktop Sync Client

The ownCloud Desktop client may stop syncing and report that SSL certificate verification failed even while the server seems reachable in a browser. That message means the client could not establish that the HTTPS server certificate is valid for the server address and trusted by the client environment. It is a TLS identity check, not a password error, and repeatedly accepting an unverified certificate can expose account credentials and files to interception.

Start with the server address, certificate validity, and certificate chain. Correct those on the server or its reverse proxy when possible. If the server intentionally uses a private certificate authority (CA), add that CA's verified root certificate to the computer's trusted store. Then restart the desktop client and confirm that synchronization resumes without a certificate warning.

First check which ownCloud client and server you use

ownCloud currently has both ownCloud Classic Server (versions 10 and 11) and ownCloud Infinite Scale (oCIS). They do not use every Desktop App release interchangeably. As of the ownCloud download page's September 1, 2026 listing, Desktop App 7.1.1 is for Infinite Scale, while ownCloud Classic is supported by a 6.x client; the page lists 6.0.3 for Classic. If a client was recently upgraded and the backend is ownCloud Server 10 or 11, check compatibility before treating a connection failure as a certificate fault.

Also confirm the exact URL configured in the sync account. The hostname in that URL must match a name in the server certificate. For a Classic server installed under a path, the account may look like https://cloud.example.com/owncloud; an oCIS installation may use a different base URL. Use the address configured by your administrator rather than switching between a hostname, IP address, and alternate domain.

Work through the likely causes in order

1. Check the date, network, and exact server name

Make sure the computer's date, time, and time zone are correct. A badly wrong clock can make a currently valid certificate appear expired or not yet valid. Next, open the exact ownCloud URL from the sync account in a browser on the same computer. Inspect the certificate details for the hostname, expiration date, and issuer. A browser that loads the page without a warning is a useful clue, but it does not prove the desktop client uses the same certificate store or that every WebDAV request follows the same proxy path.

If the failure only appears on hotel, airport, school, or public Wi-Fi, finish that network's sign-in portal and retry. ownCloud's Desktop App release notes describe pausing sync when a captive portal causes a certificate mismatch, then restarting synchronization after the portal is cleared. A portal page intercepting HTTPS is not a reason to trust the unexpected certificate.

2. Check the certificate presented by the server

Ask the server administrator to verify the TLS certificate on the public endpoint, including the web server or reverse proxy that terminates HTTPS. The certificate should be current, include the exact DNS name used by the client, and be served with the required intermediate certificates. A common deployment error is configuring only the leaf certificate instead of the full chain. If the certificate was renewed recently, make sure the reverse proxy is presenting the new certificate rather than a stale one.

On a system with OpenSSL, you can inspect the TLS handshake and check the hostname with this command. Replace the example name with the ownCloud hostname, without the URL path:

openssl s_client -connect cloud.example.com:443 \
  -servername cloud.example.com \
  -verify_hostname cloud.example.com \
  -verify_return_error </dev/null

Review the verification result and certificate dates. This test examines the endpoint from the computer where you run it; it does not reproduce every detail of the desktop client's trust store. If the output identifies an expired certificate, hostname mismatch, missing issuer, or untrusted CA, correct the certificate or chain at the TLS endpoint and test again. Do not try to fix a server-side hostname or chain problem by installing an unrelated certificate on every desktop.

3. Use a publicly trusted certificate when the server is public

For an internet-facing ownCloud service, the most straightforward fix is usually a certificate issued by a public CA trusted by current operating systems. Configure the HTTPS endpoint with the certificate and full chain for the public hostname, and verify that renewal is working. If a reverse proxy handles HTTPS, the certificate belongs on that proxy; changing only the ownCloud application configuration will not change the certificate clients receive.

After the administrator updates the endpoint, test the exact hostname from the same network as an affected computer. The browser and command-line checks should no longer report a certificate warning, and the ownCloud client should reconnect after a retry or restart. If only some computers still fail, compare their operating-system updates, trust stores, proxy settings, and client builds.

4. Trust a private CA only when the server is meant to use one

Organizations often use an internal CA for private ownCloud services. In that case, obtain the organization's root CA certificate through an authenticated channel and verify its fingerprint with the administrator. Install the root CA on each affected client computer using the operating system's certificate-management process, or the enterprise's managed device policy. Do not add a certificate downloaded from the warning page as a root merely because the sync client offers it; first verify that it belongs to the intended CA.

• Windows: an administrator can use the Certificates snap-in in Microsoft Management Console and import the verified root into the appropriate Trusted Root Certification Authorities store. Follow your organization's policy on whether trust is per-user or for the whole computer.
• macOS: use Keychain Access to add the verified certificate to the appropriate keychain and review its trust settings. Apple documents adding certificate files to a keychain; managed Macs should receive private roots through the organization's device-management process.
• Ubuntu: for a PEM-formatted CA certificate, place a .crt file in /usr/local/share/ca-certificates/ and run sudo update-ca-certificates. This updates the system trust store for applications that use it. Ubuntu cautions that Snap applications may not automatically use certificates added to the host store, so a confined package can need a package-specific trust solution.

Restart the ownCloud Desktop client after updating trust. The client package and operating system can affect which certificate store it reads. If a CA is installed and a browser trusts the site but the desktop app still fails, check the client package's trust behavior and logs instead of importing multiple copies of the server certificate at random.

Do not confuse desktop trust with ownCloud server certificate imports

ownCloud Server has an occ security:certificates command for certificates the server itself must trust, such as certificates used for federation or external storage. That is a server-side trust store. It does not repair the trust decision made by a user's desktop sync client when connecting to the ownCloud website. For a desktop verification error, fix the HTTPS endpoint or the affected computer's trust configuration.

Avoid disabling certificate validation as a permanent workaround. The ownCloud command-line client documents a --trust option, but suppressing or accepting a verification failure does not repair an expired certificate, incorrect hostname, missing CA chain, or untrusted connection. Use such trust controls only under a deliberate, verified test plan, not as a replacement for correct TLS configuration on a production sync account.

Confirm that synchronization is healthy

1. Close and reopen the ownCloud Desktop client after correcting the certificate or trust store.
2. Confirm the account status changes from an SSL or reconnect error to a connected or syncing state, with no new certificate warning.
3. Make a small test file in the sync folder and confirm it appears on the server. Then make a small change in the web interface and confirm it reaches the desktop.
4. Review the client log for a successful HTTPS/WebDAV connection if the status remains unclear. The ownCloud 5.3 troubleshooting guide documents opening Advanced > Log Settings or using F12, Ctrl+L, or Cmd+L to show the log window. Menu names may differ in other client versions.

If the website opens but sync still cannot connect after TLS checks pass, move on to WebDAV and server configuration. The ownCloud Desktop App uses WebDAV for ownCloud Classic; the vendor's troubleshooting guide recommends checking that the WebDAV endpoint is reachable when all clients fail but browser access works. If the certificate error has disappeared but login or synchronization still fails, investigate the separate authentication, reverse-proxy, or WebDAV error shown in the log.

What success looks like

The certificate presented for the configured hostname is in date, contains that hostname, and chains to a CA trusted by the client computer. The desktop client reconnects without a certificate prompt, and a test file syncs in both directions. If a public certificate chain is correct but only a single managed client continues to fail, focus next on that computer's clock, trust store, network proxy, captive portal, and compatible client version.

These checks address certificate-verification failures. They cannot correct unrelated account, WebDAV, firewall, or server availability problems, and exact menus vary across operating systems and ownCloud Desktop App releases. Use the client logs and the server's TLS endpoint configuration to identify which side still disagrees.

Official references

• ownCloud Desktop App downloads and server compatibility
• ownCloud Desktop App release notes
• ownCloud Desktop App troubleshooting and logs
• ownCloud Server: Accessing files using WebDAV
• Ubuntu: Install a root CA certificate in the trust store
• Microsoft: Trusted Root Certification Authorities store
• Apple: Add certificates to a keychain on Mac
• OpenSSL: s_client diagnostics