Fix SSL/TLS Certificate Errors for Cloud Connections in RcloneView

April 9, 2026 · 6 min read

Senior Engineer

SSL/TLS certificate errors prevent RcloneView from establishing secure connections to cloud providers. These errors range from expired certificates to corporate proxy interception — here is how to diagnose and resolve them.

Every connection RcloneView makes to a cloud provider uses HTTPS with TLS encryption. The TLS handshake verifies the server's identity through its SSL certificate. When this verification fails, RcloneView cannot connect — no browsing, no transfers, no sync. Certificate errors are especially common in corporate environments with SSL-inspecting proxies, when connecting to self-hosted storage (MinIO, Nextcloud, Seafile), or when system time is incorrect.

Manage & Sync All Clouds in One Place

RcloneView is a cross-platform GUI for rclone. Compare folders, transfer or sync files, and automate multi-cloud workflows with a clean, visual interface.

One-click jobs: Copy · Sync · Compare
Schedulers & history for reliable automation
Works with Google Drive, OneDrive, Dropbox, S3, WebDAV, SFTP and more

WindowsmacOSLinux

Get Started Free →

Free core features. Plus automations available.

Common Error Messages

"x509: certificate signed by unknown authority": The server's certificate was issued by a Certificate Authority (CA) that your system does not trust. Common with self-hosted storage and corporate proxies.
"x509: certificate has expired or is not yet valid": The certificate's validity period does not match the current system time. Either the certificate is genuinely expired or your system clock is wrong.
"x509: certificate is valid for X, not Y": The certificate's Common Name or Subject Alternative Names do not match the hostname you are connecting to. This happens when the endpoint URL does not match the certificate.
"tls: failed to verify certificate": A generic TLS verification failure. Check the full error message for specifics.
"remote TLS connection closed unexpectedly": The TLS handshake was interrupted, often by a firewall or proxy.

Fix 1: Check System Clock

The simplest and most commonly overlooked cause: your system clock is wrong. TLS certificates have a validity window (Not Before / Not After). If your clock is outside this window, every certificate appears invalid.

On Windows, check Settings > Time & Language > Date & Time and ensure "Set time automatically" is enabled. On Linux, run timedatectl and verify the time is correct. On macOS, check System Preferences > Date & Time.

A system clock that is off by even a few hours can trigger certificate errors, especially for certificates that were recently issued or are close to expiration.

Fix 2: Corporate Proxy / SSL Inspection

Many corporate networks use an SSL-inspecting proxy that intercepts HTTPS connections, decrypts them for inspection, and re-encrypts them with the organization's own certificate. This effectively performs a man-in-the-middle operation that is trusted by company-managed machines (because the corporate CA is installed in the system trust store) but may not be trusted by rclone's embedded certificate bundle.

To fix this, you need to tell rclone to use your system's certificate store or provide the corporate CA certificate explicitly:

Option A: Set the --ca-cert flag in RcloneView's custom flags to point to the corporate CA certificate file. For example: --ca-cert /path/to/corporate-ca.pem.
Option B: On Linux, ensure the corporate CA certificate is installed in the system trust store (/etc/ssl/certs/ on Debian/Ubuntu, /etc/pki/tls/certs/ on RHEL/CentOS). Run update-ca-certificates after adding the certificate.
Option C: On Windows, if the corporate CA is installed in the Windows certificate store, rclone may not use it by default (it uses its own Go TLS implementation). Export the corporate CA from the Windows certificate store as a PEM file and use --ca-cert.

Contact your IT department to obtain the corporate CA certificate if you do not have it.

Fix 3: Self-Signed Certificates (Self-Hosted Storage)

When connecting to self-hosted storage like MinIO, Nextcloud via WebDAV, or a private SFTP server with a self-signed TLS certificate, rclone will reject the connection because the certificate is not issued by a trusted CA.

You have two options:

Recommended: Add your self-signed certificate to the system trust store or use --ca-cert to point to the certificate file. This maintains TLS verification while trusting your specific certificate.
Not recommended but sometimes necessary: Use --no-check-certificate in the custom flags. This disables certificate verification entirely, making the connection vulnerable to man-in-the-middle attacks. Only use this for testing on trusted networks, never in production.

For MinIO specifically, consider generating a proper certificate using Let's Encrypt (free) instead of using a self-signed certificate.

Fix 4: Expired Server Certificate

If the cloud provider's certificate has genuinely expired, there is nothing you can do on the client side — the provider needs to renew it. This is rare for major providers (AWS, Google, Microsoft, Dropbox) but can happen with smaller providers or self-hosted solutions.

Verify by checking the certificate in a web browser: navigate to the provider's URL and click the lock icon to view certificate details. If the certificate is expired, contact the provider. For self-hosted storage, renew the certificate using your CA or Let's Encrypt.

Fix 5: Hostname Mismatch

Certificate hostname mismatches occur when the URL you are connecting to does not match the certificate's Common Name or Subject Alternative Names. This is common when:

You connect to an S3-compatible endpoint using an IP address instead of the hostname.
The endpoint URL has a typo or uses a different subdomain than the certificate covers.
You are accessing a service through a load balancer or reverse proxy that presents a different certificate.

Fix by using the exact hostname that the certificate was issued for. Check the remote configuration in RcloneView's Remote Manager and verify the endpoint URL matches the certificate's hostnames.

Fix 6: Update rclone and RcloneView

Older versions of rclone may use an outdated certificate bundle that does not include newer Certificate Authorities. Update to the latest version of RcloneView, which includes an updated rclone binary with current CA certificates.

Diagnosing Certificate Issues

When a certificate error occurs, gather details using RcloneView's built-in terminal:

Run rclone lsd remote: with --verbose to see the full error message including certificate details.
Use openssl s_client -connect endpoint:443 (if available) to inspect the server's certificate chain.
Check the certificate's issuer, expiration date, and Subject Alternative Names to identify the specific problem.

Getting Started

Download RcloneView from rcloneview.com.
If you encounter certificate errors, check your system clock first.
For corporate environments, obtain and configure the corporate CA certificate.
For self-hosted storage, add the self-signed certificate to your trust store.

SSL/TLS certificate errors are always resolvable — the fix depends on whether the issue is your system clock, a corporate proxy, a self-signed certificate, or an expired server certificate. Identifying the root cause from the error message is the key to a quick resolution.

Related Guides: