Hi,
From what you’ve described, it looks like your Nextcloud AIO instance is directly exposed to the internet without a reverse proxy – in the “Reverse proxy and version” section, you wrote “N/A”.
In such a setup, Let’s Encrypt cannot issue a certificate if there’s GeoIP filtering or other restrictions on ports 80/443. The ACME challenge simply fails.
A proper solution here is to place a reverse proxy – such as NGINX Proxy Manager – in front of AIO. This approach:
- handles Let’s Encrypt certificates directly (no need for AIO to contact ACME),
- ensures only necessary services are exposed publicly,
- allows routing multiple domains or services cleanly,
- and keeps the AIO setup safely inside your internal network.
Additionally, this setup would even allow you to run both your old and new Nextcloud servers simultaneously, each accessible via a separate domain or subdomain (e.g., cloud-old.domain.com and cloud.domain.com). That’s very useful during migrations or testing.
For reference – this is the exact setup I use (AIO running on one VM, NGINX Proxy Manager on a separate VM):
My post with docker-compose.yml and NGINX Proxy Manager configuration
Summary:
-
docker-compose.ymlfor AIO runs the interface on port6789, withAPACHE_PORT=11000. -
In NGINX Proxy Manager, I forward the domain to
IP:11000, not to AIO’s port 443. -
Under the Advanced tab in NPM, I add:
client_body_buffer_size 512k; proxy_read_timeout 86400s; client_max_body_size 0;
With this setup, Let’s Encrypt works flawlessly – no SSL errors, no failed ACME challenges.