[Feature request] Improovements on installation without cert and reverse proxy

[Migsi]

I usually use this script to setup Nextcloud instances on Free-/TrueNAS that use either self signed certs or Let's Encrypt certs, which always went fine. But now I'm confronting the situation where I have to use a reverse proxy to allow hosting of multiple sites on the same public IPv4. I'm using Nginx for that task and everything runs fine as long as I set the proxy to reencrypt the traffic (Client --\<TLS>--> Nginx --\<TLS>--> Caddy/Nextcloud). For performance reasons (low power CPU, proxy -> caddy communication over virtual net in the same machine) I tried to disable TLS on the Caddy/Nextcloud side (using the NO_CERT template), but I am unable to get a working connection that way. I kept all proxy rules in the Nextcloud config to ensure the rewrites don't mess around, but still I just get blank pages.

I'd appreciate to get any input that might help resolve this issue and I'm willing to perform a PR after adding such setup to the script.

Regards

[gt2416]

Can you access nextcloud using your internal ip ? If yes then the caddy config is correct but the reverse proxy nginx probably has an issue. I use a similar setup as you running the caddy no-ssl config and have another reverse proxy. (caddy again). Also when using a reverse proxy make sure you do redirects for calendars and contacts on the reverse proxy.

[Migsi]

After a bit of tinkering, I managed to get access via plain http. Still, the nginx reverse proxy shows a "blank" page. It seems the redirect to the login is not followed, allthough I can't see why that doesn't happen. This is my Caddy config:

{
        # debug
        default_sni 192.168.0.16
        auto_https off
}

192.168.0.16:80 {
        root * /usr/local/www/nextcloud
        file_server
        log {
                output file /var/log/mydomain.com.log
                format single_field common_log
        }

        php_fastcgi 127.0.0.1:9000 {
                env front_controller_active true
        }

        redir /.well-known/carddav /remote.php/dav 301
        redir /.well-known/caldav /remote.php/dav 301

        # .htaccess / data / config / ... shouldn't be accessible from outside
        @forbidden {
                path /.htaccess
                path /data/*
                path /config/*
                path /db_structure
                path /.xml
                path /README
                path /3rdparty/*
                path /lib/*
                path /templates/*
                path /occ
                path /console.php
        }

        respond @forbidden 404
}

and this my Nginx reverse proxy config:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name mydomain.com;
    ssl_certificate /usr/local/etc/letsencrypt/live/mydomain.com/fullchain.pem;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/mydomain.com/privkey.pem;
    include "/usr/local/lib/python3.7/site-packages/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf";
    client_max_body_size 0;
    client_body_buffer_size 128m;

    location / {
        proxy_pass http://192.168.0.16/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
    }
    location /updater/ {
        proxy_pass http://192.168.0.16/updater/;
        proxy_read_timeout 600s;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;
    }
    location /.well-known/carddav/ {
        return 301 $scheme://$host/remote.php/dav;
    }
    location /.well-known/caldav/ {
        return 301 $scheme://$host/remote.php/dav;
    }
}

[Migsi]

Okay, after thinking through the whole config from the beginning again, I figured I messed it up with the Host header. Caddy didn't have a matching host, thus responded with nothing, even thouh a defailt sni was set. I fixed this by adding the host to the caddy config, which brought me to the point where nextcloud complained about accessing it from a non trusted domain. So I had to add the host to the trusted_domains list (besides beeing within the trusted_proxies list already) and voilà, it worked.

The issue itself seems solved to me, so I could close it. But I'd be happy if we first could sort out if such config (meaning this particular way) does even make sense or if it would make more "sense" to throw away the Host header alltogether and make use of all those overwritexyz policies nextcloud provides instead? The advantage of my current setup is, that I could directly access nextcloud from my local network via http if I ever needed to. I'm unsure though if this might pose a security risk of some sort.