[13-0.7 & 14.0.2] /.well-known/caldav and carddav #11787

terrar · 2018-10-11T23:16:43Z

Steps to reproduce

Upgrade from 13.0.7 to 14.0.2 and also from 14.0.1 to 14.0.2

Expected behaviour

Upgrade without errors

Actual behaviour

Error message:
Dein Web-Server ist nicht richtig eingerichtet um "/.well-known/caldav" aufzulösen. Weitere Informationen findest Du in der Dokumentation.
Dein Web-Server ist nicht richtig eingerichtet um "/.well-known/carddav" aufzulösen. Weitere Informationen findest Du in der Dokumentation.

Server configuration

Operating system: Ubuntu 16.0.4

Web server: apache2

Database: mysql

PHP version: 7

Updated from an older Nextcloud/ownCloud or fresh install: upgrade

This .htacces settings should not produce the error message above i think:
(they were generated automatically but it seems hey do not work)

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT}  DavClnt
  RewriteRule ^$         /remote.php/webdav/          [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

The text was updated successfully, but these errors were encountered:

nextcloud-bot · 2018-10-11T23:28:13Z

GitMate.io thinks possibly related issues are #11752 (13.0.7), #11751 (14.0.2), #8766 (Caldav ), #11713 (13.0.7 RC 2), and #2649 (Upgrade from 10.0.2 to 11.0.0 breaks carddav and caldav URIs).

shieldwed · 2018-10-12T07:18:01Z

Same behaviour here. Before the upgrade this message wasn't displayed. I don't think there's a real problem though, as my synchronization with DAVdroid is still working after the upgrade. Just the message keeps saying that there is a misconfiguration.

My setup is nextcloud fpm in the official docker images with an nginx webserver in front of it. I didn't change my webserver configuration regarding these well-known URLs for the upgrade though.

timm2k · 2018-10-12T07:24:14Z

This should be fixed with PR #11738. May opcache isn't recognizing a new php source file?

MorrisJobke · 2018-10-12T07:58:35Z

Background of this:

/.well-known/caldav is a autodiscovery URL - that means it is only used during a setup of a sync
this URL is used so that the end user don't need to know the full URL of the service, but only the domain - then this URL is a redirect to the actual URL of CalDAV
this URL always needs to be in the root of the domain: https://cloud.example.com/.well-known/caldav and not in https://cloud.example.com/nextcloud/.well-known/caldav
Nextcloud is installed into the root: we can register the URL within apache automatically via the htaccess file only if the nextcloud is installed in the root as well
Nextcloud is installed into a subfolder: the admin needs to setup the proper redirect in the Webserver itself, because this is out of the scope of Nextcloud - this basically means that https://cloud.example.com/.well-known/caldav should point to https://cloud.example.com/nextcloud/remote.php/dav

Does that helps to understand the problem here?

MorrisJobke · 2018-10-12T08:03:56Z

See also https://docs.nextcloud.com/server/14/admin_manual/issues/general_troubleshooting.html#service-discovery for this.

MorrisJobke · 2018-10-12T08:04:50Z

I guess that all your instances are in a subfolder, which then explains this message. The check itself was broken before 14.0.2 and thus didn't showed up. I will close this. If this is not the case for your instance we are happy to help with further steps.

9R · 2018-10-12T09:20:25Z

I am seeing the same error message since the update to 14.0.2.
I am running Nextcloud in the root of the domain on a nginx. The redirects in the webservers config are configured as suggested in the documentation and when accessing the .well-known links remotely as well as locally they are redirected to remote.php/dav as expected.
So I suspect the check fails in some cases although the redirects actually work.

MorrisJobke · 2018-10-12T09:24:14Z

So I suspect the check fails in some cases although the redirects actually work.

Could you open the webdev tools in your browser and check the network tab for what it actually requests and what the response is? Open the network tab and then refresh the admin page to see all requests.

terrar · 2018-10-12T09:36:18Z

I get this error here on FF. (apache2)

9R · 2018-10-12T09:39:34Z

Could you open the webdev tools in your browser and check the network tab for what it actually requests and what the response is? Open the network tab and then refresh the admin page to see all requests.

Request:
Request-URL: `https://foo.bla/.well-known/caldav`
Request method: PROPFIND

Response-Header:
content-length: 185
content-type: text/html
date: Fri, 12 Oct 2018 09:30:23 GMT
location: `http://foo.bla/remote.php/dav`
referrer-policy: no-referrer
server: nginx/1.14.0
strict-transport-security: max-age=15768000
x-content-type-options: nosniff
x-download-options: noopen
X-Firefox-Spdy: h2
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block

ptrunk · 2018-10-12T10:13:24Z

I think the problem here is that we are redirected from https to http which is denied by "Content Security Policy". I have the same problem with my nginx + fpm docker setup after the 14.0.2 update

9R · 2018-10-12T10:27:19Z

Ah, right. I forgot to mention that. In my case the nginx running Nextcloud is behind a reverse proxy handling ssl. That proxy redirects all http request to https which has not caused any problems yet.

Changing the redirect rule for in the nginx config for Nextcloud-site from

return 301 $scheme://$host/remote.php/dav;

to

return 301 https://$host/remote.php/dav;

to force connection directly via https fixed the issue for me.

MorrisJobke · 2018-10-12T10:54:30Z

@ptrunk @9R Does this also solve the issue for you?

9R · 2018-10-12T11:05:36Z

@MorrisJobke Yes, changing the nginx config as I described above removed the error message for me

terrar · 2018-10-12T11:25:06Z

any hint what i have to change in apache2 so solve this?

blackcrack · 2018-10-12T11:37:12Z

https://help.nextcloud.com/t/php-errors-with-nextcloud-14-0-2/38942/3
#11789
#11789 (comment)

9R · 2018-10-12T12:19:03Z

@terrar the response code (405) in your screenshot suggest, that your current apache setup blocks PROPFIND requests. Check the apache documentation how to allow those.
After that .htaccess rules in the link @MorrisJobke posted above should resolve the issue.

ghtux · 2018-10-12T15:24:11Z

Ah, right. I forgot to mention that. In my case the nginx running Nextcloud is behind a reverse proxy handling ssl. That proxy redirects all http request to https which has not caused any problems yet.

Changing the redirect rule for in the nginx config for Nextcloud-site from
return 301 $scheme://$host/remote.php/dav;
to
return 301 https://$host/remote.php/dav;
to force connection directly via https fixed the issue for me.

This helped, thanks! Sync for dav is working fine but nextcloud still shows /.well-known/caldav error while testing settings.

pzwahlen · 2018-10-13T08:50:49Z

I'm running 14.0.2 on Apache behind an HAProxy. Apache listens on 80 and HAProxy does the SSL termination.

Both Chrome and Firefox have this issue and the console log is quite clear:

Refused to connect to 'http://example.com/remote.php/dav/' because it violates the following Content Security Policy directive: "connect-src 'self'".

Why is the server requesting those checks to be done over http rather than https ? I have tried with 'overwriteprotocol' => 'https' and it doesn't help.

I don't have a 14.0.1 anymore and wonder if the checks were done over https, or if the CSP policy was different.

pzwahlen · 2018-10-15T20:08:11Z

Replying to myself,

I just re-installed a 14.0.1 and apparently the browser was not trying to reach .well-known URLs at all during the check in older versions.

Therefore the problem seems to be new requests to those URLs (over http) rather than a CSP change.

MorrisJobke · 2018-10-16T06:14:21Z

I just re-installed a 14.0.1 and apparently the browser was not trying to reach .well-known URLs at all during the check in older versions.

Yes we fixed this in 14.0.2. The check was never done before.

The refused request is due to the downgrade from https to http. I would recommend you to check that the redirect is setup correctly.

pzwahlen · 2018-10-16T12:40:36Z

@MorrisJobke Thanks for the clarification.

Just to be clear, if I open a new blank browser tab, I see this:

https://example.com/.well-known/caldav -> 301 -> http://example.com/remote.php/dav/ -> 307 -> https://example.com/remote.php/dav/

The first 301 redirect comes from Nextcloud and the second 307 comes from HAProxy, which means (to me) that the http->https redirect config is correct.

The problem is why does Nextcloud return a plaintext (http) in the first 301.

When I do the same from the settings admin page, my understanding is that the browser refuses to open the http plaintext request, because it violates the CSP.

I also understand the admin pages generates PROPFIND requests versus me testing with GET requests.

I'm still pretty confident that my HAProxy correctly redirects http to https (for all URLS to a given hostname) and I still see this issue.

MorrisJobke · 2018-10-16T14:43:32Z

When I do the same from the settings admin page, my understanding is that the browser refuses to open the http plaintext request, because it violates the CSP.

Yes - this should be like that.

What web server do you use? By any chance Nginx? Then this might be nextcloud/documentation#899

pzwahlen · 2018-10-16T16:02:43Z

@MorrisJobke as mentioned above I'm running Nextcloud on CentOS7/Apache, listening on port 80 only. Another host is running HAProxy with a TLS frontend.

I'm redirecting all HTTP trafic to HTTPS (no filter based on specific URLs) and I'm not touching the content, other than adding an x-Forwarded-For header to the requests.

I'm still questioning why the browser would receive or build an HTTP plain text URL where it should send HTTPS requests only.

I have tried (and failed) to understand how this URL is constructed and so far I don't even understand if it's built in JS (browser-side) or if it is somehow pushed by he server.

I can also confirm that during the check, the HAProxy doesn't receive a single HTTP request (only HTTPS) so it doesn't have a chance to perform any redirect to HTTPS.

For me, the problem is really that this HTTP URL shouldn't be there in the first place and the browser correctly blocks the connection because of the CSP.

Thanks for looking into this.

MorrisJobke · 2018-10-17T07:13:44Z

@MorrisJobke as mentioned above I'm running Nextcloud on CentOS7/Apache, listening on port 80 only. Another host is running HAProxy with a TLS frontend.

Check out the proxy configuration: https://docs.nextcloud.com/server/14/admin_manual/configuration_server/reverse_proxy_configuration.html maybe this helps in your setup to properly do the redirect.

As this seems to be a setup issue I would like to ask you to raise your question in the forums: https://help.nextcloud.com

If you wish support with setup issues from Nextcloud GmbH we offer this as part of the Nextcloud subscription. Learn more about this at https://nextcloud.com/enterprise/

gorlilla · 2018-11-12T17:12:30Z

@pzwahlen i have nextcloud running on apache2 behind an apache2 reverse proxy. i was having same issue with the check failing on admin control panel and was seeing the same CSP failures. Ultimately i tried hard coding the https://foo.bar to the 301 redir via .htaccess and nextcloud.conf and also ensuring the correct paramaters were set for:

'overwrite.cli.url' => https://foo.bar, #FQDN (my nextcloud sits in webroot of subdomain) 'overwriteprotocol' => 'https',

i was still getting the error but i noticed that when i ran:

curl -i http://foo.bar/.well-known/caldav
i was getting the correct 301 redirect to https:// BUT when i ran

curl -i https://foo.bar/.well-known/caldav
the 301 redirect was pointing to http://

i resolved this by adding the hard-coded 301 redirects including full https://foo.bar to my nextcloud virtual host (note that my nextcloud only has an http virtual host since TLS is offloaded at proxy).

Might help -- might not, but i think it is likely a configuration issue after all.

mfechner · 2018-11-16T09:50:12Z

Ah, right. I forgot to mention that. In my case the nginx running Nextcloud is behind a reverse proxy handling ssl. That proxy redirects all http request to https which has not caused any problems yet.

Changing the redirect rule for in the nginx config for Nextcloud-site from
return 301 $scheme://$host/remote.php/dav;
to
return 301 https://$host/remote.php/dav;
to force connection directly via https fixed the issue for me.

Thanks, this seems to be the only solution for this problem.
Maybe the documentation here should be adapted:
https://docs.nextcloud.com/server/14/admin_manual/installation/nginx.html

Tuffiglig · 2018-12-29T08:45:45Z

Hey.
I changed my Port.
I had to changed it to:
return 301 $scheme://$host:12345/remote.php/dav;
to get it working.

rubo77 · 2019-10-01T12:33:54Z

In case you use nginx, just add this to the config before the location / { block:

  location = /.well-known/carddav {
      return 301 /remote.php/dav;
  }
  location = /.well-known/caldav {
      return 301 /remote.php/dav;
  }

jimi3 · 2020-12-19T10:35:27Z

Ah, right. I forgot to mention that. In my case the nginx running Nextcloud is behind a reverse proxy handling ssl. That proxy redirects all http request to https which has not caused any problems yet.

Changing the redirect rule for in the nginx config for Nextcloud-site from
return 301 $scheme://$host/remote.php/dav;
to
return 301 https://$host/remote.php/dav;
to force connection directly via https fixed the issue for me.

Thanks, had the same problem with haproxy and apache2 running nextcloud.example.com, this solved my problems too.

nextcloud-bot added the bug label Oct 11, 2018

MorrisJobke closed this as completed Oct 12, 2018

MorrisJobke mentioned this issue Oct 15, 2018

wrong warnings after upgrade to 14.0.2 (and 14.0.3) #11825

Closed

MorrisJobke mentioned this issue Oct 29, 2018

Server not properly set up to solve well-known/caldav and well-known/carddav after upgrade from 14.0.1 to 14.0.3 #11850

Closed

kesselb mentioned this issue Nov 21, 2018

Setup check for "/.well-known/{caldav,carddav}" not satisfiable on multiple instances per subdomain #12572

Closed

kesselb mentioned this issue Aug 20, 2019

.well-known check behind proxy using path is requesting a wrong URL #16817

Closed

kesselb mentioned this issue Jan 17, 2020

Cannot configure caldav and carddav and fatal error #18922

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[13-0.7 & 14.0.2] /.well-known/caldav and carddav #11787

[13-0.7 & 14.0.2] /.well-known/caldav and carddav #11787

terrar commented Oct 11, 2018 •

edited

Loading

nextcloud-bot commented Oct 11, 2018

shieldwed commented Oct 12, 2018

timm2k commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

9R commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

terrar commented Oct 12, 2018 •

edited

Loading

9R commented Oct 12, 2018

ptrunk commented Oct 12, 2018

9R commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018 •

edited

Loading

9R commented Oct 12, 2018

terrar commented Oct 12, 2018

blackcrack commented Oct 12, 2018 •

edited

Loading

9R commented Oct 12, 2018

ghtux commented Oct 12, 2018 •

edited

Loading

pzwahlen commented Oct 13, 2018 •

edited

Loading

pzwahlen commented Oct 15, 2018

MorrisJobke commented Oct 16, 2018 •

edited

Loading

pzwahlen commented Oct 16, 2018

MorrisJobke commented Oct 16, 2018

pzwahlen commented Oct 16, 2018

MorrisJobke commented Oct 17, 2018

gorlilla commented Nov 12, 2018

mfechner commented Nov 16, 2018

Tuffiglig commented Dec 29, 2018

rubo77 commented Oct 1, 2019 •

edited

Loading

jimi3 commented Dec 19, 2020

[13-0.7 & 14.0.2] /.well-known/caldav and carddav #11787

[13-0.7 & 14.0.2] /.well-known/caldav and carddav #11787

Comments

terrar commented Oct 11, 2018 • edited Loading

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration

nextcloud-bot commented Oct 11, 2018

shieldwed commented Oct 12, 2018

timm2k commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

9R commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018

terrar commented Oct 12, 2018 • edited Loading

9R commented Oct 12, 2018

ptrunk commented Oct 12, 2018

9R commented Oct 12, 2018

MorrisJobke commented Oct 12, 2018 • edited Loading

9R commented Oct 12, 2018

terrar commented Oct 12, 2018

blackcrack commented Oct 12, 2018 • edited Loading

9R commented Oct 12, 2018

ghtux commented Oct 12, 2018 • edited Loading

pzwahlen commented Oct 13, 2018 • edited Loading

pzwahlen commented Oct 15, 2018

MorrisJobke commented Oct 16, 2018 • edited Loading

pzwahlen commented Oct 16, 2018

MorrisJobke commented Oct 16, 2018

pzwahlen commented Oct 16, 2018

MorrisJobke commented Oct 17, 2018

gorlilla commented Nov 12, 2018

mfechner commented Nov 16, 2018

Tuffiglig commented Dec 29, 2018

rubo77 commented Oct 1, 2019 • edited Loading

jimi3 commented Dec 19, 2020

terrar commented Oct 11, 2018 •

edited

Loading

terrar commented Oct 12, 2018 •

edited

Loading

MorrisJobke commented Oct 12, 2018 •

edited

Loading

blackcrack commented Oct 12, 2018 •

edited

Loading

ghtux commented Oct 12, 2018 •

edited

Loading

pzwahlen commented Oct 13, 2018 •

edited

Loading

MorrisJobke commented Oct 16, 2018 •

edited

Loading

rubo77 commented Oct 1, 2019 •

edited

Loading