.well-known seems to work but still a warning (using Traefik)

I have nextcloud up and running using Traefik as proxy. When I navigate to my-cloud.de/.well-known/caldav I get redirected to my-cloud.de/remote.php/dav - which I think is correct. However, in the settings I still get a warning

Your web server is not properly set up to resolve “/.well-known/caldav”.

Also, while I’m able to connect the calendar on my phone, it fails on OSX. I’m assuming, has to do with this “.well-known” issue.

There have been quite some questions around this topic in this forum, however, most are about configuring Apache, I’m using Traefik. The configuration is:

      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.regex=/.well-known/(card|cal)dav"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.replacement=/remote.php/dav/"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.permanent=true"
      - traefik.http.services.nextcloud.loadbalancer.server.port=80

Do I have to set any headers, maybe?

1 Like

i use “replacepathregex” instead of “redirectregex”:

nevertheless up to now i couldn’t get rid of the webfinger warning. but remote.php/dav seems to work well.

1 Like

Hm, this does not seem to change anything. The redirect still works, but the Warning is still displayed and I cannot connect my OSX clients.

Hey, since I read your name very often here and I guess you know what you are doing I wanted to ask if you were able to resolve the well known webfinger warning?
I can’t get rid of it sadly with traefik and nextcloud:apache image.
image
Currently my traefik lables in nc look like this:
I tried different suggestions from github but couldn’t make them work.

      - "traefik.enable=true"
      - "traefik.http.routers.nextcloud-app.entrypoints=http"
      - "traefik.http.routers.nextcloud-app.rule=Host(`example.secureserver.de`)"  #set url (cloud.example.com)
      - "traefik.http.middlewares.nextcloud-app-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.nextcloud-app.middlewares=nextcloud-app-https-redirect"
      - "traefik.http.routers.nextcloud-app-secure.entrypoints=https"
      - "traefik.http.routers.nextcloud-app-secure.rule=Host(`example.secureserver.de`)"  #set url (cloud.example.com)
      - "traefik.http.routers.nextcloud-app-secure.tls=true"
      - "traefik.http.routers.nextcloud-app-secure.tls.certresolver=http"
      - "traefik.http.routers.nextcloud-app-secure.service=nextcloud-app"
      - "traefik.http.services.nextcloud-app.loadbalancer.server.port=80"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.nextcloud-app-secure.middlewares=nextcloud-dav,secHeaders@file"
      - "traefik.http.middlewares.nextcloud-dav.replacepathregex.regex=^/.well-known/ca(l|rd)dav"
      - "traefik.http.middlewares.nextcloud-dav.replacepathregex.replacement=/remote.php/dav/"

@SimonWolf I’m afraid no. I could find the correct traefik settings for this yet. sorry.

I think the issue disappeared now.
I didn’t change anything but checked again if it’s working now and it seems to be working just fine on arm aswell now…
Do you still have any Traefik warnings about well-known?
(This is the configuration I am using)

Maybe just my 50cents here, also nearly spent 2 days until I digged a bit deeper:

TL;DR;

traefik conifg for a nextcloud accessible in domainname root, e.g. https://mydomain.com/ (not in subpath)

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nextcloud.rule=Host(`$(DOMAINNAME)`)"
      - "traefik.http.routers.nextcloud.entrypoints=https"
      - "traefik.http.routers.nextcloud.tls.certresolver=myresolver"
      - "traefik.http.routers.nextcloud.middlewares=nextcloud-redirectregex1,nextcloud-redirectregex2"
      - "traefik.http.middlewares.nextcloud-redirectregex1.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex1.redirectregex.regex=https?://([^/]*)/.well-known/(card|cal)dav"
      - "traefik.http.middlewares.nextcloud-redirectregex1.redirectregex.replacement=https://$${1}/remote.php/dav/"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.regex=https?://([^/]*)(/.well-known[^#]*)"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.replacement=https://$${1}/index.php$${2}"

Why did the issue (maybe) suddenly disappeared, without any (obvious) change?

the requests to webfinger and nodeinfo get cached, so only if you wait until the cached time is over (and a real reload takes place) or if you disable the caching in F12 DevTools you get the real changes.
image

So the caching is maybe a hint here.

How to configure traefik?

For CalDav and CardDav the documentation tells a little bit on how to configure traefik here
Reverse proxy — Nextcloud latest Administration Manual latest documentation, which in labels is already mentioned here:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nextcloud.rule=Host(`$(DOMAINNAME)`)"
      - "traefik.http.routers.nextcloud.entrypoints=https"
      - "traefik.http.routers.nextcloud.tls.certresolver=myresolver"
      - "traefik.http.routers.nextcloud.middlewares=nextcloud-redirectregex"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.regex=https?://(.*)/.well-known/(card|cal)dav"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.replacement=https://$${1}/remote.php/dav/"

unfortunatley for webfinger and nodeinfo nothing is said.

I looked at an nginx example configuration here
https://github.com/nextcloud/docker/blob/211229f8dc1ddbede16f7bb67d4bcada75d6a047/.examples/docker-compose/with-nginx-proxy/mariadb/fpm/web/nginx.conf#L100-L117

this configures the nginx like that:

# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
    # The rules in this block are an adaptation of the rules
    # in `.htaccess` that concern `/.well-known`.

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

    location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
    location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

    # Let Nextcloud's API for `/.well-known` URIs handle all other
    # requests by passing them to the front-end controller.
    return 301 /index.php$request_uri;
}

the formerly seen traefik labels are for these two lines

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

result for traefik

      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.regex=https?://(.*)/.well-known/(card|cal)dav"
      - "traefik.http.middlewares.nextcloud-redirectregex.redirectregex.replacement=https://$${1}/remote.php/dav/"

but for this part

# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;

nothing is provided. So in other words the webfinger request to e.g.https://mydomain.com/.well-known/webfinger should be redirected to https://mydomain.com/index.php/.well-known/webfinger

so I added a new middleware

      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.regex=https?://([^/]*)(/.well-known[^#]*)"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.replacement=https://$${1}/index.php$${2}"

The regex is a little bit special and it is essential to understand as otherwise it leads to issues and you get an endless redirect.
my nextcloud is available via https://mydomain.com/ so NO SUB PATH, for sub path the regex needs to be adapted.

What the regex right now does:
https?://([^/]*)(/.well-known[^#]*)

  • the first match group ([^/]*) only matches the host and port information (host [ “:” port ]) - up before the first occurrence of a /
  • the second group (/.well-known[^#]*) matches the full original request URI (with arguments) but without any fragment/comment/anchor, if it starts with /.well-known - this group content is comparable to the nginx.conf variable $request_uri

The second group then gets appended to the new location: https://$${1}/index.php$${2}

Why the first group is so important:
This redirect is different than the one for Cal/CardDav, it appends the magic string /.well-known again, to the new url: https://mydomain.com/index.php/.well-known/webfinger
so the regex needs to ensure that the redirected url is NOT matched again, otherwise you end in an endless redirection loop: https://mydomain.com/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/index.php/.well-known/webfinger

The regex can be tested e.g. here:
regex101: build, test, and debug regex
Sample Urls

  • https://mydomain.com/.well-known/webfinger
  • https://mydomain.com/.well-known/webfinger/longersample
  • https://mydomain.com/.well-known/webfinger#anchor_should_not_match

Full configuration:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nextcloud.rule=Host(`$(DOMAINNAME)`)"
      - "traefik.http.routers.nextcloud.entrypoints=https"
      - "traefik.http.routers.nextcloud.tls.certresolver=myresolver"
      - "traefik.http.routers.nextcloud.middlewares=nextcloud-redirectregex1,nextcloud-redirectregex2"
      - "traefik.http.middlewares.nextcloud-redirectregex1.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex1.redirectregex.regex=https?://([^/]*)/.well-known/(card|cal)dav"
      - "traefik.http.middlewares.nextcloud-redirectregex1.redirectregex.replacement=https://$${1}/remote.php/dav/"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.permanent=true"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.regex=https?://([^/]*)(/.well-known[^#]*)"
      - "traefik.http.middlewares.nextcloud-redirectregex2.redirectregex.replacement=https://$${1}/index.php$${2}"

More Details

Uniform Resource Identifiers:
By RFC URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers, and finally the combination of Uniform Resource Locators (URL). As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify–via name, location, or any other characteristic–a resource.

Further Sources:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2
http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri

4 Likes

@BobSilent Thanks a lot for your excellent research work, it works with Traefik 2.9 and NC app 25.0.2.

I’m currently trying to adapt BobSilent’s RedirectRegex2 to work with Traefik in fileConfig.yml.

This is the progress so far,
However I’m not sure how to get it working past what I have done so far.

If anyone could help I would greatly appreciate it!

Thanks,

    nextcloud-redirectregex:
      redirectRegex:
        permanent: true
        regex: 'https://(.*)/.well-known/(card|cal)dav'
        replacement: 'https://${1}/remote.php/dav/'
    nextcloud-redirectregex2:
      redirectRegex:
        permanent: true
        regex: 'https://([^/]*)(/.well-known[^#]*)'
        replacement: 'https://${1}/index.php${2}'   

this works fine for me

    nextcloud-redirect:
      replacepathregex:
        regex: "^/.well-known/(cal|card)dav"
        replacement: "/remote.php/dav/"

together with docker-compose directive

 - traefik.http.routers.nextcloud.middlewares=nextcloud-redirect@file

use comma to separate in case you want to add multiple middlewares e.g. =nextcloud-redirect@file,secHeaders@file

Hello,

I am trying to get rid of the following errors.

This is my Traefik fileConfig.yml

    nextcloud:
      headers:
        referrerPolicy: "no-referrer"
        browserXSSFilter: true
        contentTypeNosniff: true
        customFrameOptionsValue: "SAMEORIGIN"
        customRequestHeaders: 
          X-Forwarded-Proto: https
    nextcloud-redirect:
        replacepathregex:
          regex: "^/.well-known/(cal|card)dav"
          replacement: "/remote.php/dav/"
    nextcloud-webfinger:
        replacepathregex:
          regex: "^(/.well-known.*)"
          replacement: "/index.php$${1}"

I followed what @wwe had for cal card dav, and that made those errors disappear but the node and webfinger still appear. Nextcloud docs dont mention anything about this. And what @BobSilent showed did not work.

I’m only running the regex: "^/.well-known/(cal|card)dav" replacement and don’t see any warning regarding webfinger in my traefik v2.9+NC25 official Apache docker installation… :man_shrugging:

but interesting enough it seems only DAV redirection works… still no error.

image

That’s interesting, so would you say its not something to worry about?

apparently not. according to other posts /.well-known/nodeinfo and /.well-known/webfinger must be redirected to /index.php/.well-known/nodeinfo and /index.php/.well-known/webfinger… but accessing this URLs results in “webfinger/nodeinfo not supported” (in NC 25.0.3)… definitely nothing to care about for now… but would be good to update reverse proxy config for the case this features become supported in the future

UPDATE: little more investigation shows my config fooled me a little. apache docker image already uses rewrite rules for <mydomain/* to /index.php/* this is the reason why /.well-known/nodeinfo and /.well-known/webfinger works out of the box with traefik and no additional rewrite rule is required (only (cal|card)dav needs special handling)… the server still responds with http status 404 but returns the “… not supported” JSON message as payload as well.

@wwe I’m using Traefik and Nextcloud on unraid but that shouldn’t make a difference.

I also found that
chrome_rCGV8NU9Et
Its requesting at http:// but when you click the link it will redirect to https://

So what do I need to change?

I’m sorry no idea about unraid specifics - my experience is based on plain docker Apache image (maybe you use FPM variant?).
If your Nextcloud runs on https:// but generates URLs with plain http:// prefix it makes me think you missed some overwrite* settings… please review Reverse proxy — Nextcloud latest Administration Manual latest documentation

Managed to get it solved,

Referenced: Nextcloud Docker with Traefik Reverse Proxy for Beginners | SHB

Basically just copied and pasted…

TraeFik File Config:

 nextcloud-middlewares-secure-headers:
      headers:
        accessControlMaxAge: 100
        sslRedirect: true
        stsSeconds: 63072000
        stsIncludeSubdomains: true
        stsPreload: true
        forceSTSHeader: true
    ### We will modify this value for Nextcloud to remove the X-Frame-Options error:
        customFrameOptionsValue: "SAMEORIGIN" #CSP takes care of this but may be needed for organizr.
        contentTypeNosniff: true
        browserXssFilter: true
#       sslForceHost: true # add sslHost to all of the services
#       sslHost: "example.com"
        referrerPolicy: "no-referrer"
    ### While CSP is a good security setting, Nextcloud's Apache server takes care of this for us!
#       contentSecurityPolicy: "frame-ancestors '*.example.com:*';object-src 'none';script-src 'none';"
        featurePolicy: "camera 'none'; geolocation 'none'; microphone 'none'; payment 'none'; usb 'none'; vr 'none';"
        customResponseHeaders:
    ### Change this to none to remove the Robots error:
          X-Robots-Tag: "none"
          server: ""
 
### This section redirects requests for Nextcloud calendar and contacts service discovery
### source: https://docs.nextcloud.com/server/21/admin_manual/issues/general_troubleshooting.html#service-discovery
    nextcloud-redirect:
      redirectRegex:
        permanent: true
        regex: "https://(.*)/.well-known/(card|cal)dav"
        replacement: "https://${1}/remote.php/dav/"

    chain-nextcloud:
      chain:
        middlewares:
          - nextcloud-middlewares-secure-headers
          - nextcloud-redirect

Labels:

 # We set 'enable by default' to false, so this tells Traefik we want it to connect here
  - "traefik.enable=true"
  ## HTTP Routers
  - "traefik.http.routers.nextcloud.entrypoints=https"
  - "traefik.http.routers.nextcloud.rule=Host(`yourdomain.tld`)"
  - "traefik.http.routers.nextcloud.tls=true"
  ## Middlewares
  - "traefik.http.routers.nextcloud.middlewares=chain-nextcloud@file" 
  ## HTTP Services
  - "traefik.http.routers.nextcloud.service=nextcloud"
  - "traefik.http.services.nextcloud.loadbalancer.server.port=80"

Only issue now is the X-Robots-Tag… Could this be because of the PHP version?

You can solve the ‘X-Robots Tag’ warning by changing X-Robots-Tag: "none" to X-Robots-Tag: "noindex, nofollow"
in your middlewares file.

Hi @Cody_B,

I came accross you post here in search of trying to fix the “/.well-known/webfinger”, “/.well-known/nodeinfo”, “/.well-known/caldav” & “/.well-known/carddav” errors.

I am also running unraid, I have Nextcloud set up via Traefik and I’m also using aAuthetik, Authentik is bypassed for Nextcloud but I am not using Docker compose like the guide you have sent above, I am setting the config via labels on the docker template.

Was wondering if you could help me along with the config and how your set up looks?

Hey there,

I made the switch to the NextCloud AIO, and it got rid of 99% of my issues.

I’ve updated my traefik config file as well.

    nextcloud-secure-headers:
        headers:
          hostsProxyHeaders:
             - "X-Forwarded-Host"
          referrerPolicy: "same-origin"

    https-redirect:
       redirectscheme:
         scheme: https 

    nextcloud-chain:
     chain:
         middlewares:
            # - ... (e.g. rate limiting middleware)
            - https-redirect
            - nextcloud-secure-headers

I also have it bypassing authentik, but I also have it being manually routed in traefik.

nextcloud:
        rule: 'Host(`----------`)'
        entrypoints:
            - "https"
        service: nextcloud
        middlewares:
            - nextcloud-chain
        tls:
                certresolver: "letsencrypt"
1 Like