Cannot validate domain (curl 35 error)

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • AIO version v13.3.1
  • Operating system and version (e.g., Ubuntu 24.04):
    • Raspberry Pi OS (trixie)
  • Web server and version (e.g, Apache 2.4.25):
    • AIO built-in
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • caddy 2.11.4
  • PHP version (e.g, 8.3):
    • AIO built-in
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • Validating domain
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO/docker
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

I am trying to setup Nextcloud AIO with caddy reverse proxy and my own domain (shown as nextcloud.mydomain.com in the text below, bought from Porkbun, which also provides SSL certificates) but I keep receiving a curl error. I am using Pihole as my DNS server to help since my router does not support NAT loopback and have moved it’s ports off 80/443 to prevent interference with Nextcloud. I’m really struggling to find what the issue is, although I haven’t used the SSL certificates from Porkbun yet as I haven’t found a clear way to do so in the AIO instructions. Any help would be greatly appreciated!

Steps to replicate it:

  1. Forward ports 80 and 443 to my Raspberry Pi’s internal IP.
  2. Add local DNS record for nextcloud.mydomain.com & my Raspberry Pi’s internal IP to Pihole (not installed on docker). Pihole’s webserver ports are modified in config (80 ⇒ 9080, 443 ⇒ 9443).
  3. Add Raspberry Pi as DNS server in my router.
  4. Create compose.yaml file with the contents below (modified from here as suggested by the comments).
    name: nextcloud-aio
    services:
     nextcloud-aio-mastercontainer:
       image: ghcr.io/nextcloud-releases/all-in-one:latest
       init: true
       restart: always
       container_name: nextcloud-aio-mastercontainer
       volumes:
         - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
         - /var/run/docker.sock:/var/run/docker.sock:ro
       network_mode: bridge
       ports:
         - "8080:8080"
       environment:
         APACHE_PORT: 11000
         APACHE_IP_BINDING: 0.0.0.0
    
     caddy:
       image: caddy:alpine
       restart: always
       container_name: caddy
       volumes:
         - caddy_certs:/certs
         - caddy_config:/config
         - caddy_data:/data
         - caddy_sites:/srv
       network_mode: "host"
       configs:
         - source: Caddyfile
           target: /etc/caddy/Caddyfile
    configs:
     Caddyfile:
       content: |
         https://nextcloud.mydomain.com:443 {
           reverse_proxy localhost:11000
         }
    
    volumes:
     nextcloud_aio_mastercontainer:
       name: nextcloud_aio_mastercontainer
     caddy_certs:
     caddy_config:
     caddy_data:
     caddy_sites:
    
  5. Run docker compose up -d and login to AIO interface.
  6. Attempt to validate mydomain.com and receive the error “Domain does not point to this server or the reverse proxy is not configured correctly. See the mastercontainer logs for more details. (‘sudo docker logs -f nextcloud-aio-mastercontainer’)” from AIO interface.

Nextcloud log (docker):

NOTICE: PHP message: Info: It seems like the ip-address of nextcloud.mydomain.com is set to an internal or reserved ip-address. (It was found to be set to '192.168.50.63')
NOTICE: PHP message: The response of the connection attempt to "https://nextcloud.mydomain.com:443" was: 
NOTICE: PHP message: Expected was: 3f77029772b2737caf88d6f46ed565dc451a89b237c4499f
NOTICE: PHP message: The error message was: cURL error 35: TLS connect error: error:0A000438:SSL routines::tlsv1 alert internal error (see https://curl.se/libcurl/c/libcurl-errors.html) for https://nextcloud.mydomain.com
NOTICE: PHP message: Please follow https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md#how-to-debug in order to debug things!

Bumping, if anyone needs more information let me know and I’ll provide. Thanks!

The issue you are seeing here is that Caddy does (most likely) not have a TLS vertificate to accept TLS connections yet. The errors come from nextcloud AiO “testing” the connection to itself, and then it gets some sort of TLS issue because Caddy is not set up with a certificate.

When you use a reverse proxy in front of AiO, you need to terminate SSL at the reverse proxy (Caddy). From Caddy going into AiO (this part: reverse_proxy localhost:11000) - that is http, and does not need a certificate.

So the reverse proxy becomes responsible to handle TLS- meaning you need to let Caddy know where to find the certificates it needs.

The reason you cannot automatically get these certs from letsencrypt comes down to this note:

I assume this record is in your PiHole or your local router. Letsencrypt cannot find this DNS.
If you wanted letsencrypt to automatically manage your certificate(s), you need to use a publicly available DNS that letsencrypt can resolve (e.g. your DNS provider for the domain). You will also make sure that both port 80 and port 443 is available publicly, this is how letsencrypt verifies the ACME challenge.

If you want to manage the certs on your own / manually, you need to follow these instructions: SSL Configuration in Caddy - Wiki - Caddy Community (See under the “custom ssl configuration” example here)