How to Configure SSL/HTTPS for ownCloud Server with Let’s Encrypt

For a directly hosted ownCloud Server instance running behind an Apache VirtualHost, the usual path is to point a public domain to the server, make the HTTP site reachable, and run Certbot’s Apache installer for that hostname. For example, if your ownCloud address is cloud.example.com, Certbot can request a Let’s Encrypt certificate and configure Apache to serve HTTPS with sudo certbot --apache -d cloud.example.com. Test the site and automatic renewal before relying on it.

This procedure is for an ownCloud Classic 10.16-style installation served by Apache on Ubuntu, as assumed by ownCloud’s Apache guide. If you run ownCloud Classic 11 in Docker, ownCloud says HTTPS must be configured on the web proxy in front of the container. If a hosting provider or reverse proxy already terminates TLS, configure the certificate there instead of trying to install it in the ownCloud container.

Check that this setup fits your server

Let’s Encrypt proves that you control the requested domain name before issuing a certificate. For the common HTTP-01 challenge, Let’s Encrypt must be able to retrieve a temporary file from your server over public HTTP on port 80. The same hostname must resolve to the public endpoint that serves your ownCloud site. HTTPS traffic then reaches the Apache endpoint on port 443.

• You have a public hostname, such as cloud.example.com, and control its DNS records.
• The hostname resolves to the public IP address of the Apache server or the public reverse proxy.
• Inbound ports 80 and 443 are allowed through the relevant firewall, router, and cloud security group.
• Apache already serves the ownCloud site through a VirtualHost for that hostname.
• You have administrator access to the machine that handles the public HTTP and HTTPS traffic.

If your site is behind a proxy, load balancer, container host, or control panel, identify where public TLS ends before running Certbot. A certificate installed on the wrong machine will not secure the browser-to-server connection. For ownCloud Classic 11, the supported Docker design manages Apache inside the container and places HTTPS at the web proxy.

Prepare the ownCloud hostname and Apache site

Use a dedicated ownCloud hostname where possible. ownCloud requires each browser URL used to log in to be listed under trusted_domains in its config/config.php file. If you are changing from an IP address or another hostname to cloud.example.com, add the new host to an unused entry in the trusted-domains array before testing the new address. Do not overwrite another entry accidentally.

Confirm that plain HTTP reaches the intended ownCloud site before requesting a certificate. In Apache, the VirtualHost should identify the exact hostname with a ServerName directive. ownCloud’s Apache instructions assume a VirtualHost configuration and, on Ubuntu, place site definitions under /etc/apache2/sites-available/. Paths and service names can differ on other distributions.

Back up the active Apache VirtualHost configuration before changing it. This gives you a recovery point if an automated installer chooses the wrong site or creates a conflicting HTTPS host. If you have multiple sites on the same server, inspect the existing VirtualHosts so the certificate is attached to the ownCloud hostname rather than the default site.

Install and run Certbot for Apache

Install Certbot using the instructions for your exact operating system and Apache setup. Certbot’s official instructions recommend its Snap package for many Linux installations, but package availability and supported installation routes depend on the distribution. Avoid mixing multiple Certbot installations from the OS package manager and Snap; the command called certbot should be the one whose Apache plugin you intend to use.

On an Ubuntu host where Snap is installed and supported, the Certbot instructions show this installation path:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

If Certbot is already installed, check which version your shell runs and how it was installed before adding another copy. Follow the current Certbot Apache installation guide for other supported installation options.

Request and install the certificate for your ownCloud hostname:

sudo certbot --apache -d cloud.example.com

Replace cloud.example.com with the real hostname. Certbot will perform domain validation and, with the Apache installer, update Apache to use the issued certificate. If you want a single certificate to cover more names, specify each name explicitly, for example -d cloud.example.com -d files.example.com. Every name listed must point to a reachable endpoint and pass validation.

Certbot may ask whether HTTP requests should be redirected to HTTPS. Enabling the redirect is appropriate once the HTTPS VirtualHost is working. ownCloud recommends HTTPS for production and a permanent redirect for unencrypted traffic. If you prefer to manage Apache configuration yourself, Certbot also provides a certificate-only mode; use ownCloud’s Apache guide to connect the certificate files and VirtualHost correctly, then test the configuration before reloading Apache.

When HTTP validation cannot reach your server

The HTTP-01 method uses a path under /.well-known/acme-challenge/ on port 80. If a router forwards port 80 to a different machine, a firewall blocks it, or another proxy routes that path elsewhere, validation can fail even though the ownCloud page loads over HTTPS. Check public DNS and port forwarding, then make sure the ACME challenge reaches the same endpoint where Certbot is running.

If your ISP or network policy blocks port 80, consider DNS-01 validation instead. It proves domain control through a DNS TXT record and can issue wildcard certificates, but renewal automation depends on whether your DNS provider has a suitable API plugin. Avoid placing broad DNS credentials on a web server when a narrowly scoped credential or a separate validation host is available. Do not use an HTTP-01-only procedure for a wildcard certificate.

Verify Apache and ownCloud after installation

Before closing the maintenance window, check that Apache configuration is valid and that Certbot lists the new certificate:

sudo apache2ctl configtest
sudo certbot certificates

On Ubuntu, a successful Apache syntax check reports that the configuration is valid. Open https://cloud.example.com in a browser and sign in. Confirm the browser shows a valid certificate for the exact hostname, and test a representative file upload, download, and sync client. If you enabled a redirect, visit the HTTP address and confirm that it lands on the same HTTPS hostname without a redirect loop.

If the ownCloud login page reports an untrusted domain, check trusted_domains in the server’s configuration. If the browser redirects to the wrong hostname or ownCloud generates HTTP links behind a reverse proxy, review the proxy’s forwarded host and HTTPS headers and the ownCloud proxy settings. Those settings depend on the proxy topology; do not copy reverse-proxy overrides into a direct Apache installation without a reason.

Check renewal before considering the job done

Let’s Encrypt’s standard certificates are short-lived, so renewal must be automated. Certbot installations commonly provide a systemd timer or cron job. Test renewal in advance with:

sudo certbot renew --dry-run

A dry run checks the renewal path without replacing the live certificate. If it fails, read the Certbot output and correct the stated DNS, firewall, challenge-routing, or Apache problem. Confirm that a timer or scheduled task exists with your operating system’s service tools; do not assume renewal is active just because the first certificate was issued. Keep port 80 available if your renewal uses HTTP-01, or ensure your DNS-01 automation can still update the required TXT record.

Common choices and pitfalls

Do not enable HSTS with includeSubDomains until every relevant subdomain is served correctly over HTTPS; a header on one hostname affects how browsers treat its subdomains. First make the certificate, redirects, and renewal reliable. Then review ownCloud’s hardening guidance for HSTS and other TLS settings appropriate to your complete domain layout.

Documentation checked October 6, 2026. The exact file paths and commands below assume Ubuntu with Apache and ownCloud Classic 10.16; Docker, reverse-proxy, hosting-panel, Nginx, and non-Ubuntu deployments need instructions for their actual TLS endpoint.

References: ownCloud 10.16: Configure Apache with Let’s Encrypt; ownCloud 11: HTTPS and reverse-proxy guidance; ownCloud 10.16: trusted domains; Certbot: Apache installation and renewal; Let’s Encrypt: challenge types; Let’s Encrypt: keeping port 80 open.