Nextcloud problems / questions

Good day , Thank you again for helping me out!

This morning Joulinar :sunrise:

  1. I start and use the empty config file from

nano /etc/nginx/sites-enabled/default

# /etc/nginx/sites-available/default
server {
	listen 80 default_server;
	listen [::]:80 default_server;

	root /var/www;
	index index.php index.html index.htm index.nginx-debian.html;

	server_name "$hostname";

	include /etc/nginx/sites-dietpi/*.conf;

	location / {
		try_files $uri $uri/ =404;
	}

	location ~ \.php(?:$|/) {
		include snippets/fastcgi-php.conf;
		fastcgi_pass php;
	}
}

Did a reboot to be sure

  1. Run the DietPi-LetsEncrypt
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for hemertje.com and nextcloud.hemertje.com
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Enhancement Strict-Transport-Security was already set.
Enhancement Strict-Transport-Security was already set.
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Your existing certificate has been successfully renewed, and the new certificate
has been installed.

The new certificate covers the following domains: https://YourDomain.com and
https://YourDomain.hemertje.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/YourDomain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/YourDomain.com/privkey.pem
   Your certificate will expire on 2023-03-31. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again with the "certonly" option. To non-interactively
   renew *all* of your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

[ INFO ] DietPi-LetsEncrypt | Applying HTTPS domain to known web application configs
[  OK  ] DietPi-LetsEncrypt | sed -i s|'http://localhost/nextcloud'|'https://YourDomain.com/nextcloud'| /var/www/nextcloud/config/config.php
[  OK  ] DietPi-LetsEncrypt | Desired setting in /etc/nginx/sites-dietpi/dietpi-nextcloud.conf was already set:         add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
[  OK  ] DietPi-LetsEncrypt | systemctl restart nginx

Press any key to return to the DietPi-LetsEncrypt menu ...

The config /etc/nginx/sites-available/default now looks like

# /etc/nginx/sites-available/default
server {

        root /var/www;
        index index.php index.html index.htm index.nginx-debian.html;

        server_name YourDomain.com;

        include /etc/nginx/sites-dietpi/*.conf;

        location / {
                try_files $uri $uri/ =404;
        }

        location ~ \.php(?:$|/) {
                include snippets/fastcgi-php.conf;
                fastcgi_pass php;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/YourDomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/YourDomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


    ssl_trusted_certificate /etc/letsencrypt/live/YourDomain.com/chain.pem; # managed by Certbot
    ssl_stapling on; # managed by Certbot
    ssl_stapling_verify on; # managed by Certbot

}


server {

        root /var/www;
        index index.php index.html index.htm index.nginx-debian.html;
    server_name nextcloud.YourDomain.com; # managed by Certbot

        include /etc/nginx/sites-dietpi/*.conf;

        location / {
                try_files $uri $uri/ =404;
        }

        location ~ \.php(?:$|/) {
                include snippets/fastcgi-php.conf;
                fastcgi_pass php;
        }

    listen [::]:443 ssl ; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/YourDomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/YourDomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot




    ssl_trusted_certificate /etc/letsencrypt/live/YourDomain.com/chain.pem; # managed by Certbot
    ssl_stapling on; # managed by Certbot
    ssl_stapling_verify on; # managed by Certbot


}
server {
    if ($host = YourDomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 default_server;
        listen [::]:80 default_server;

        server_name YourDomain.com;
    return 404; # managed by Certbot


}
server {
    if ($host = nextcloud.YourDomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 ;
        listen [::]:80 ;
    server_name nextcloud.YourDomain.com;
    return 404; # managed by Certbot


}
  1. you should have HTTPS access to Nginx default web site on both, domain and sub domain
    Yes indeed
    Until here I see the domain and sub domain

4-9 gaves me problems this morning

Will look further next year

Guten rutsch ins neue jahr !

:wave: :beers: :clinking_glasses:

what exactly was the issue on #5?

Dir auch einen guten Rutsch.

I fixed the issue in case server_name directive is present multiple times: v8.13 · MichaIng/DietPi@02d5d9d · GitHub
I wasn’t aware that Certbot adds all vhosts to the same single default config. I do now wonder whether this is requires at all or whether Certbot adds/updates the server_name directive automatically in any case, so that we can skip this step completely?

Hallo @Joulinar and @MichaIng

Dir und Deiner Familie ein frohes, erfolgreiches, liebevolles und gesundes neues Jahr und viel Spaß bei der Entwicklung und Betreuung von DietPi!

@MichaIng How to try this?
Just update DietPi

root@DietPi:~# dietpi-launcher

 DietPi-Update
─────────────────────────────────────────────────────
 Phase: Checking for available DietPi update

[  OK  ] DietPi-Update | Checking IPv4 network connectivity
[  OK  ] DietPi-Update | Checking DNS resolver
[ INFO ] DietPi-Update | Getting latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version
[  OK  ] DietPi-Update | Got valid latest version: 8.12.1
[  OK  ] DietPi-Update | No update required, your DietPi installation is already up to date:
[ INFO ] DietPi-Update | Current version : v8.12.1
[ INFO ] DietPi-Update | Latest version  : v8.12.1
[ INFO ] DietPi-Update | Checking for new available live patches
[ INFO ] DietPi-Update | APT update, please wait...
Hit:1 https://deb.debian.org/debian bullseye InRelease
Get:2 https://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:3 https://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:4 https://deb.debian.org/debian bullseye-backports InRelease [49.0 kB]
Hit:5 https://armbian.hosthatch.com/apt bullseye InRelease
Get:6 https://deb.debian.org/debian bullseye-backports/main arm64 Packages.diff/Index [63.3 kB]
Get:7 https://deb.debian.org/debian bullseye-backports/main arm64 Packages T-2023-01-02-0212.56-F-2023-01-02-0212.56.pdiff [1222 B]
Get:7 https://deb.debian.org/debian bullseye-backports/main arm64 Packages T-2023-01-02-0212.56-F-2023-01-02-0212.56.pdiff [1222 B]
Fetched 206 kB in 4s (47.4 kB/s)
Reading package lists...
[  OK  ] DietPi-Update | APT update
[ INFO ] DietPi-Update | No APT upgrades were found, not creating file: /run/dietpi/.apt_updates
 - Press any key to return to DietPi-Launcher...

Or which file to edit and have a try?

The statement from @MichaIng was not directly related to your question. It was more an enhancement how our script dietpi-letsencrypt will handle creating multiple domains in future. But this has nothing to do with your change of the root directory for NC.

After setting back the original nano /etc/nginx/sites-available/default file I ran dietpi-letsencrypt

The following line(s) are missing to add the ‘includeSubDomains"’

Search the original line
add_header Strict-Transport-Security "max-age=31536000" always; # managed by Certbot

and replace with
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # managed by Certbot

@MichaIng
Can this also be added automaticly when running dietpi-letsencrypt with the HSTS option set to ON?

:ok_hand: :ok_hand: :ok_hand:

this should not be needed. Simply adjust the web server root directory as stated above.

Back to you solutiuon and question

Now I have Nextcloud accessibele at:

https://nextcloud/apps/dashboard/ (with http - with a red warning not secure)

At https://nextcloud.YourDomain.com/ I get

# Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to [nginx.org](http://nginx.org/).
Commercial support is available at [nginx.com](http://nginx.com/).

*Thank you for using nginx.*

At https://YourDomain.com/nextcloud/login I see the NC welcome login page

did you adjusted the web server root directory for the sub domain as stated above on point #5?

Doing it step by step now not to mess up :wink:

Ok, edited and re-started Nginx with

systemctl restart nginx

Now on the 3 locations a got the NC login

https:///nextcloud/apps/dashboard/
https://nextcloud.YourDomain.com/
https://YourDomain.com/nextcloud/login

further with 6…

step 6 + 7:
nano /var/www/nextcloud/config/config.php

Original:
‘overwrite.cli.url’ => ‘https://YourDomain.com/nextcloud’,

Adjusted:
‘overwrite.cli.url’ => ‘https://nextcloud.YourDomain.com’,

Step 8:
Re-started Nginx with:
systemctl restart nginx

Step 9:
Now on the 3 locations a got the NC login

https:// < local ip address > /nextcloud/ (http 404 not found / https available with not secure warning)
https://nextcloud.YourDomain.com/
https://YourDomain.com/nextcloud/login

Seems I made a type somewhere a few days ago
with systemctl restart nginx I also got a failure back

Under Security & setup warnings, I got the following:

There are some warnings regarding your setup.

  • The “Strict-Transport-Security” HTTP header is not set to at least “15552000” seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips :arrow_upper_right:.

  • Your web server is not properly set up to resolve “/.well-known/webfinger”. Further information can be found in the documentation :arrow_upper_right:.

  • Your web server is not properly set up to resolve “/.well-known/nodeinfo”. Further information can be found in the documentation :arrow_upper_right:.

  • Your web server is not properly set up to resolve “/.well-known/caldav”. Further information can be found in the documentation :arrow_upper_right:.

  • Your web server is not properly set up to resolve “/.well-known/carddav”. Further information can be found in the documentation :arrow_upper_right:.

You shouldn’t need to set any HSTS header manually. This is all managed by Certbot and should be correct. From your recent posted default file I see /etc/letsencrypt/options-ssl-nginx.conf is included. Isn’t this where the HSTS header is set, or did you miss to enable HSTS?

In an earlier version of your default file I see includeSubDomains being set for the parent YourDomain.com domain, while it is missing for the subdomain nextcloud.YourDomain.com, which is correct as well as there are no further sub-subcomains. You should be able to trust the official EFF ACME client, to set everything up correctly :wink:, at least we won’t mess with this.

For Nextcloud, however, since it is in an own location block with additional headers set (so that parent block headers do not apply), the HSTS header needs to be set again, which is done by dietpi-letsencrypt. Please check /etc/nginx/sites-dietpi/dietpi-nextcloud.conf whether it contains the header as expected, along with the webfinger, nodeinfo and DAV redirects…

… now I see the issue: Since you changed your webroot (right?), that whole file does not apply anymore. Basically you need to replace every /nextcloud with / and remove the location ^~ /nextcloud { block around its content completely + some of the contained directives shouldn’t be required anymore, like the HSTS header… Now I’m wondering why the one from default config does not apply.
Instead of editing /etc/nginx/sites-dietpi/dietpi-nextcloud.conf, I suggest to create a new one, so it’s easier to revert and Nextcloud reinstalls won’t overwrite your changes:

cp -a /etc/nginx/sites-dietpi/dietpi-nextcloud.conf /etc/nginx/sites-dietpi/my-nextcloud.conf

I’m not a coder, just a normal user who wants to understand what is installed, how it is setup and the reason behind it :wink:

Reading Nginx website https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/ states that the Strict Transport Security (STS) response header in NGINX and NGINX Plus is relatively straightforward in the file:

nano /etc/nginx/sites-available/default

Search the original line
add_header Strict-Transport-Security "max-age=31536000" always; # managed by Certbot

and replace with
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # managed by Certbot

So it’s not defined in the file as you suggest:
/etc/letsencrypt/options-ssl-nginx.conf

This options-ssl-nginx.conf file contains

# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

ssl_ciphers "ECDHE-ECDSA-AES128-G............

Not any link to set the HSTS option

My DietPi-LetsEncrypt setup:

image

I’m not a coder but reading this I think that the line

`add_header Strict-Transport-Security "max-age=31536000" always; # managed by Certbot`

should be added in the config done by the Certbot?

and when the HSTS option is set to ON the option includeSubDomains" is also should be added by the Certbot.

This morning I started with your default Nginx config DietPi/nginx.default at master · MichaIng/DietPi · GitHub

and ran the Certbot incl. Domain and Sub.Domain

This is the result:

# /etc/nginx/sites-available/default
server {

        root /var/www;
        index index.php index.html index.htm index.nginx-debian.html;

        server_name YourDomain.com;

        include /etc/nginx/sites-dietpi/*.conf;

        location / {
                try_files $uri $uri/ =404;
        }

        location ~ \.php(?:$|/) {
                include snippets/fastcgi-php.conf;
                fastcgi_pass php;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/YourDomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/YourDomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


    ssl_trusted_certificate /etc/letsencrypt/live/YourDomain.com/chain.pem; # managed by Certbot
    ssl_stapling on; # managed by Certbot
    ssl_stapling_verify on; # managed by Certbot

}
server {

        root /var/www/nextcloud;
        index index.php index.html index.htm index.nginx-debian.html;
    server_name nextcloud.YourDomain.com; # managed by Certbot

        include /etc/nginx/sites-dietpi/*.conf;

        location / {
                try_files $uri $uri/ =404;
        }

        location ~ \.php(?:$|/) {
                include snippets/fastcgi-php.conf;
                fastcgi_pass php;
        }

    listen [::]:443 ssl ; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/YourDomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/YourDomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot




    ssl_trusted_certificate /etc/letsencrypt/live/YourDomain.com/chain.pem; # managed by Certbot
    ssl_stapling on; # managed by Certbot
    ssl_stapling_verify on; # managed by Certbot

}

server {
    if ($host = YourDomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 default_server;
        listen [::]:80 default_server;

        server_name YourDomain.com;
    return 404; # managed by Certbot


}
server {
    if ($host = nextcloud.YourDomain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80 ;
        listen [::]:80 ;
    server_name nextcloud.YourDomain.com;
    return 404; # managed by Certbot


}

The lines
add_header Strict-Transport-Security "max-age=31536000" always; # managed by Certbot

or
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # managed by Certbot

are not included…

So what goes wrong or is missing?

here we go:

# Based on: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/nginx-subdir.conf.sample

# Redirect webfinger and nodeinfo requests to Nextcloud endpoint
location /.well-known/webfinger { return 301 /nextcloud/index.php$request_uri; }
location /.well-known/nodeinfo  { return 301 /nextcloud/index.php$request_uri; }

location ^~ /nextcloud {

        # Omit Nginx version on error response
        server_tokens off;

        # Set max upload size
        client_max_body_size 1048576M;
        fastcgi_buffers 64 4K;

        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rs>

        # HTTP response headers borrowed from Nextcloud `.htaccess`
        add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
        add_header Referrer-Policy "no-referrer" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Download-Options "noopen" always;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Permitted-Cross-Domain-Policies "none" always;
        add_header X-Robots-Tag "none" always;
        add_header X-XSS-Protection "1; mode=block" always;

        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;

        # Specify how to handle directories -- specifying `/nextcloud/index.php$request_uri`
        # here as the fallback means that Nginx always exhibits the desired behaviour
        # when a client requests a path that corresponds to a directory that exists
        # on the server. In particular, if that directory contains an index.php file,
        # that file is correctly served; if it doesn't, then the request is passed to
        # the front-end controller. This consistent behaviour means that we don't need
        # to specify custom rules for certain paths (e.g. images and other assets,
        # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
        # `try_files $uri $uri/ /nextcloud/index.php$request_uri`
        # always provides the desired behaviour.
        index index.php index.html /nextcloud/index.php$request_uri;

        # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
        location = /nextcloud {
                if ( $http_user_agent ~ ^DavClnt ) {
                        return 302 /nextcloud/remote.php/webdav/$is_args$args;
                }
        }

        # Rules borrowed from `.htaccess` to hide certain paths from clients
        location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
        location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }

        # Ensure this block, which passes PHP files to the PHP process, is above the blocks
        # which handle static assets (as seen below). If this block is not declared first,
        # then Nginx will encounter an infinite rewriting loop when it prepends
        # `/nextcloud/index.php` to the URI, resulting in a HTTP 500 error response.
        location ~ \.php(?:$|/) {
                fastcgi_split_path_info ^(.+?\.php)(/.*|)$;
                set $path_info $fastcgi_path_info;
                try_files $fastcgi_script_name =404;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                fastcgi_param HTTPS $https;
                fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
                fastcgi_param front_controller_active true; # Enable pretty URLs without /index.php/
                fastcgi_pass php;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
                fastcgi_max_temp_file_size 0; # Allow downloads > 1 GiB: https://github.com/nextcloud/documentation/pull/7979
        }

        location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
                try_files $uri /nextcloud/index.php$request_uri;
                expires 6M; # Cache-Control policy borrowed from `.htaccess`
                access_log off; # Optional: Don't log access to assets
        }

        location ~ \.woff2?$ {
                try_files $uri /nextcloud/index.php$request_uri;
                expires 7d; # Cache-Control policy borrowed from `.htaccess`
                access_log off; # Optional: Don't log access to assets
        }

        # Rule borrowed from `.htaccess`
        location /nextcloud/remote {
                return 301 /nextcloud/remote.php$request_uri;
        }

        location /nextcloud {
                try_files $uri $uri/ /nextcloud/index.php$request_uri;
        }
}

Not sure why it is missing now, it was present in each vhost in your first posted default config.

I see now in the Certbot output

So HSTS is/was still set somewhere in Nginx configs. Can you check:

grep -ir 'Strict-Transport-Security' /etc/nginx

Only for parent domain vhosts, not for vhosts which apply for subdomains already. At least this is the logic Certbot follows, according to your first default config, and it makes sense to me.

About /etc/nginx/sites-dietpi/dietpi-nextcloud.conf, please check the last part of my post: That file needs to be rewritten if the webroot is changed.

root@DietPi:~# grep -ir 'Strict-Transport-Security' /etc/nginx
/etc/nginx/sites-dietpi/dietpi-nextcloud.conf.dietpi-new:       #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
/etc/nginx/sites-dietpi/dietpi-nextcloud.conf:  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
/etc/nginx/sites-available/default.save:    add_header Strict-Transport-Security "max-age=31536000" always; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";# managed by Certbot
root@DietPi:~#

Sorry not sure what you mean with this above…

Can I start from zero with the installation Nexcloud incl. Certbot for Maindomain and Subdomain without my manual editing of config files?