AIO problem with reverse proxy in a docker and firewall port-forwarding

Dear experts, I’m stuck at the final stage of the installation. I follow strictly all the guides (ex. reverse-proxy.md) but still get an error when I try to register my domain and the error is:

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’)

Log file:
The response of the connection attempt to domainname:443" was: , referer: IP:8083/containers
Expected was: 61a5133240654fbd3c76fb9cde68342c7aa1ff02f0ce4221, referer: IP:8083/containers
The error message was: SSL certificate problem: self signed certificate, referer: IP:8083/containers

My configuration is: docker container with NGINX proxy manager 0.0.0.0:4443->443/tcp
upfront firewall with port forwarding from 443 → 4443 (proxy listening port), all ports open in the opposite directions. NGINX is correctly setup with letsencrypt and all the configuration is working for other services without any issue. Moreover I follow all the steps of the guide for the NGINX (localhost, port 11000,…)

My suspicious is that the when it connects to domainname:443. it is getting the certificate of the proxy…?? I don’t understand, maybe the port forwarding is creating the issue?

here the docker file

version: “3.8”

volumes:
nextcloud_aio_mastercontainer:
name: nextcloud_aio_mastercontainer

services:
nextcloud:
image: nextcloud/all-in-one:latest
restart: always
container_name: nextcloud-aio-mastercontainer
volumes:
- nextcloud_aio_mastercontainer:/mnt/docker-aio-config
- /var/run/docker.sock:/var/run/docker.sock:ro
ports:
#- 80:80
- 8083:8080
#- 8443:8443
environment:
- APACHE_PORT=11000
#- APACHE_IP_BINDING=127.0.0.1 # Should be set when running behind a web server or

Thanks in advance for your help.

P.S. I omitted all the https because of topic limitation

Hi, can you also post the docker-compose of nginx proxy manager and a screenshot of the rp config? Thanks!

Btw, for what service is port 443 currently used on your server?

services:
app:
image: ‘jc21/nginx-proxy-manager:latest’
restart: unless-stopped
ports:
# These ports are in format :
- ‘80:80’ # Public HTTP Port
- ‘4443:443’ # Public HTTPS Port
- ‘81:81’ # Admin Web Port
# Add any other Stream port you want to expose
# - ‘21:21’ # FTP
environment:
DB_MYSQL_HOST: “db”
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: “npm”
DB_MYSQL_PASSWORD: “npm”
DB_MYSQL_NAME: “npm”
# Uncomment this if IPv6 is not enabled on your host
# DISABLE_IPV6: ‘true’
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
depends_on:
- db
networks:
- frontend
- backend

db:
image: ‘jc21/mariadb-aria:latest’
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: ‘npm’
MYSQL_DATABASE: ‘npm’
MYSQL_USER: ‘npm’
MYSQL_PASSWORD: ‘npm’
volumes:
- ./data/mysql:/var/lib/mysql
networks:

Thanks for the support. I have some update.

I think I have different the problems:

First one the “domain-checking” container is using the curl command that it seems to return the positive feedback only with the option --insecure. The certificate is properly signed by letsencrypt but curl it does not like it, so it will always fail. Maybe you can fix it in this function all-in-one/ConfigurationManager.php at f07f1e1deb06c64bfe77a46a89ed71992151c889 · nextcloud/all-in-one · GitHub

The other problem that I cannot reach “localhost” simply because docker is in a bridge mode, the option that is suggested in the guide " --network host option (or network_mode: host for docker-compose)" is inapplicable for me ( and I guess many users) and the workaround simply cannot work from a bridge network.

Now everything is working using:

  • SKIP_DOMAIN_VALIDATION=true

and in nginx you need to use http://nextcloud-aio-apache instead of localhost port 11000. (To work this, you need to connect nginx to the same network of the containers of nextcloud)

With this workaround it will work but still the Talk container would not work, it still listening on the host side and nginx cannot use twice the same domain name.

Thanks

Good that you found a solution to this.

The talk port is indeed opened on the host but does must not be proxied via npm. Instead, can you simply open the required port in your router? Then it should usually work.