Closed droogi closed 3 years ago
did you checked on the nextcloud forum as I suggested on the forum?
Many thanks for your report. The HSTS warning is expected as long as you didn't enable it intentionally via e.g. dietpi-letsencrypt
or which whichever method you enabled HTTPS. Just note that you should only do this when you don't see a reason to allow plain HTTP connections any longer for any of your clients, as they will store the information and won't connect via HTTP any longer (which is the goal of HSTS).
EDIT: Ah sorry, I didn't read till the end. So you had HSTS enabled already but reverted it by copying whole config. But no problem, only uncomment the following line to enable the header: https://github.com/MichaIng/DietPi/blob/dev/.conf/dps_114/nginx.nextcloud.conf#L27
The webfinger and nodeinfo warnings should actually be solved. I'll have a look tomorrow.
@joulinar, i tried to understand the nextcloud documentation for nginx (thats not the forum), but i get mixed up since dietpi uses not the same way how to configure nginx - sites enabled. I do not understand the syntax and do not have knowledge and experience to figure out and just tried copy and paste in hopefully the correct file.
Just in case: "uncomment" means to remove the leading hash #
sign from:
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
So it changes from a config code comment into an actual directive.
While the config has it commented by default, to work with plain HTTP setups or with HTTPS but no HSTS, we uncomment it when running dietpi-letsencrypt
with HSTS option enabled.
@MichaIng, when using the dps_114 original complete code i was able to uncomment this line, but still have the webfinger/nodeinfo issue. thanks for explanation. (offtopic: i just renewed letsencrypt certificate, but i had to open port 80 on router which is usually not forwarded, so no automatic renewals possible?)
letsencrypt
requires port 80 to be open to obtain the certificate
Yes. With HTTPS redirect enabled there is also no reason to keep port 80 closed. Read the statement of Let's Encrypt about this: https://letsencrypt.org/docs/allow-port-80/
Strange, I cannot replicate the issue. Installed Nextcloud + Nginx on a clean DietPi Buster image and the redirects solve the warnings as expected.
If it doesn't work in your case, please provide your Nginx config via nginx -T
, but be sure to remove all identifying things like domains/hostnames and such.
Hello MichaIng, i also tried to copy the 3 lines to /etc/nginx/sites-dietpi/dietpi-dav_redirect.conf, but no success. (i used the redirect in one conf-file only and left the other conf-file untouched). to be sure: the error is described in nextcloud 21.0.1, Admin Account, settings-overview-Security & setup warnings : Your web server is not properly set up to resolve "/.well-known/webfinger ....../nodeinfo nginx.conf.log
Strange, tested another time and it really works here OOTB. Also the method matches 100% the one from Nextcloud docs (where I just recently helped updating). Can you please run the following from the command line:
curl -IL https://your.domain.org/.well-known/webfinger/test
when i run the the command i get this result: webfingertest.log when i change to curl -IL https://your.domain.org/nextcloud/.well-known/webfinger/test the second result: webfingertest2.log
So the redirect is done as intended. Of course the final access fails, as it you cannot authenticate via curl, only the first redirect is relevant.
Strange that the Nextcloud admin panel shows it otherwise. Did you try to restart the webserver and PHP and clear the browser cache as well to rule that all out?
systemctl restart nginx
systemctl restart php7.3-fpm
And CTRL+F5
to reload the page in browser.
i always restarted nginx, (also restarted dietpi), now i also restarted php7.3-fpm, cleared cache in firefox and chrome, reloaded page, still get the warning. So you think its an nextcloud warning error?
Is this still an issue? Whatever I do, I cannot replicate it, so it is neither a general bug in Nextcloud, not on our config. All configs and tests (aside of the admin panel) look correct and have exactly expected results. So I'm puzzled.
I updated to 21.0.2 stable about 2 weeks ago, nextcloud still displays webfinger / nodeinfo error message. I updated dietpi from 7.1.2 to 7.2.3 today, nextcloud still displays webfinger / nodeinfo error message.
Since i am using Nextcloud only private for me and my family, and the installation and connected devices work well, its no problem for me. I do not have any disadvantages when the message is displayed.
If you were interested to solve, i could give you an account/ssh, but i am fine when its not solved. Thanks for your support.
Looping through old open issues. Another attempt: In /var/www/nextcloud/config/config.php
you have
'overwrite.cli.url' => 'http://localhost/nextcloud',
right?
I never though about that a HTTPS redirect means this is redirected to https://localhost/nextcloud
, which fails as localhost
is no valid domain for the certificate. So this needs to be changed to contain https://your.domain.org/nextcloud
for CLI calls to succeed, which likely implies the webfinger/nodeinfo calls.
I'll add this to dietpi-letsencrypt
, to update ownCloud and Nextcloud configs regarding this setting.
dietpi 7.5.2 & nextcloud 22.1.1
I changed http://localhost/nextcloud
(http) to https://mydomain.org/nextcloud
(https) in /var/www/nextcloud/config/config.php
The warning in nextcloud is still there.
I attached my current /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
.
i noticed
location ^~ /nextcloud {
block.and
location ~ ^/.well-known/(?:webfinger|nodeinfo) { .....
in my config file.
(in windows a system32/config/host has to be configured to redirect the domain to localhost, where is this done here?)
Did you restart PHP to assure possible caches are cleared?
systemctl restart php7.3-fpm
The config is as expected:
https://mydomain.org/.well-known/webfinger
to https://mydomain.org/nextcloud/index.php/.well-known/webfinger
, so within the /nextcloud
block the rule would never apply 😉.location ~ ^/.well-known
syntax means a location matching the "regular expression" (~
), which starts (^
) with /.well-known
.location ^~ /nextcloud
syntax means a location which starts "literally" with /nextcloud
and that no further location directive should be searched for (^~
).Okay I tested it the other way round, and indeed overwrite.cli.url
doesn't have an effect on those tests but only on the Cron job and occ
(ncc
) command.
Another thing you could try is to update the `.htaccess to rule out any possibly old conflicting rewrite:
ncc maintenance:update:htaccess
Thanks for the detailed explanation. I updated the `.htaccess, without success. It seems I am the only one with this config message in nextcloud, so for me it's ok to archive/close this topic.
Next big aim for me it's to upgrade to 64 bit to get OpenOffice in nextcloud (when wireguard works) and import all certificates.
Okay, let me keep it open to have the overwrite.cli.url
change implemented into dietpi-letsencrypt
, which is required to allow Cron jobs and occ commands accessing Nextcloud via HTTPS.
Done: https://github.com/MichaIng/DietPi/commit/9909a4f750c1ed50719d74b3dbc995fc4abee992 Changelog: https://github.com/MichaIng/DietPi/commit/1fda33db0cd1d8dd318b7b6f035aaf47a4b2d6ef
I know it was not the solution for your actual issue, but it is a solution for other potential issues, e.g. in combination with apps who do check via access through the webserver. I'm still wondering how the admin panel redirect check can succeed when the invalid localhost URL is given while a HTTPS redirect or HSTS is present. There shouldn't be any other reliable way than accessing Nextcloud externally through the webserver. I'll check the related code at Nextcloud by times.
sorry i cannot code, only report...
my nextcloud 21.0.1 installation on dietpi 7.1.2 says its not well configured because of missing webnode and nodeinfo configuration. (nginx)
i added /etc/nginx/sites-dietpi/dietpi-nextcloud.conf in line 4-5 with
location ~ ^/.well-known/(?:webfinger|nodeinfo) { return 301 /nextcloud/index.php$request_uri; }
as you write in /.conf/dps_114/nginx.nextcloud.conf after restarting service nginx i still have same error message in nextcloud
(in forum https://dietpi.com/phpbb/viewtopic.php?p=33770#p33770)
when i copy the complete code from dps_114 in a new nginx.nextcloud.conf i get a third safety hint: Strict-Transport-Security" is not min. 15552000 Seconds, activation of hsts is recommended.
Do you have any advice?
Regards, droogi