Your web server is not properly set up to resolve webfinger and nodeinfo

ℹ️ Support
, , , , ,
1

[details=“Support intro”]

Hello, I’m new in Nextcloud and this is my first server configured, it is configured with Nginx and php8.3. NC version is 28.0.4. I’ve got this issue since I configured it for the first time and doesn’t really affect my server but I want to solve it. I tried all possible solutions that I finded and no sloution did work for me. If someone could help me I would be grateful, thx.

nextcloud conf:

    location ^~ /.well-known {
        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }
        return 301 /index.php$request_uri;
    }
            location = /.well-known/webfinger   { return 301 /index.php$uri; }
            location = /.well-known/nodeinfo   { return 301 /index.php$uri; }

    location ~ /\.well-known/acme-challenge {
        allow all;
    }

.htaccess conf:

  RewriteRule ^\.well-known/webfinger https://ncloud.grupospaserv.com:43443/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^\.well-known/nodeinfo https://ncloud.grupospaserv.com:43443/index.php/.well-known/nodeinfo [R=301,L]
1 Like
2

I’m curious about the solution to this as well, I copied exactly the example nginx config from the documentation:

        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;
        }

But I still have those errors complaining that webfinger, nodeinfo, carddav, and webdav aren’t set up properly.

I can also curl /.well-known/nodeinfo and see that the nginx config is correctly 301 redirecting to /index.php/.well-known/nodeinfo:

curl 'https://nextcloud.mydomain.com/.well-known/nodeinfo' -D -
HTTP/2 301 
content-type: text/html
date: Thu, 25 Apr 2024 00:49:29 GMT
location: http://nextcloud.mydomain.com/index.php/.well-known/nodeinfo
referrer-policy: no-referrer
server: nginx
strict-transport-security: max-age=15768000; includeSubDomains; preload;
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
content-length: 162

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

But if I do curl -L so that it follows the redirect, the url at http://nextcloud.mydomain.com/index.php/.well-known/nodeinfo returns a 404 the message “nodeinfo not supported”:

curl 'https://nextcloud.mydomain.com/.well-known/nodeinfo' -L -D -
HTTP/2 301 
content-type: text/html
date: Thu, 25 Apr 2024 00:51:20 GMT
location: http://nextcloud.mydomain.com/index.php/.well-known/nodeinfo
referrer-policy: no-referrer
server: nginx
strict-transport-security: max-age=15768000; includeSubDomains; preload;
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
content-length: 162

HTTP/2 404 
cache-control: no-cache, no-store, must-revalidate
content-security-policy: default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none'
content-type: application/json; charset=utf-8
date: Thu, 25 Apr 2024 00:51:20 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT
feature-policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none'
pragma: no-cache
referrer-policy: no-referrer
server: nginx
set-cookie: oc_sessionPassphrase=xxxxxx; path=/; secure; HttpOnly; SameSite=Lax
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
set-cookie: xxxxx=xxxxx; path=/; secure; HttpOnly; SameSite=Lax
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-nextcloud-well-known: 1
x-permitted-cross-domain-policies: none
x-request-id: 5rcPEkbguHe2IY9Zubdi
x-robots-tag: noindex, nofollow
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
content-length: 36

{"message":"nodeinfo not supported"}%

So it seems like the .well-known resolves correctly, it’s just that it gives a 404 at that url. Maybe that’s just because I don’t have any federation plugins installed, but then the error message should be saying “you don’t have any federation stuff installed” instead of saying “your web server is not set up to resolve .well-known”…

3

I have no clue of what happened but i think it just fixed itself, if you need help I can post my configuration to help you if you want.

server {
    listen 80;
    server_name xxx;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name xxx
    ssl_certificate xxx
    ssl_certificate_key xxx

    # Add headers to serve security related headers 
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag "noindex, nofollow";
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Referrer-Policy no-referrer;
    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
    add_header Cache-Control "public, max-age=3600";
    add_header Vary "Host";
    add_header X-Cache $upstream_cache_status;
    add_header X-Frame-Options "SAMEORIGIN";

    root xxx;

    access_log /var/log/nginx/nextcloud.access;
    error_log /var/log/nginx/nextcloud.error;

        location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

    location ^~ /.well-known {
        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }
        return 301 /index.php$request_uri;
    }

     location ^~ /.well-known/carddav {
        return 301 $scheme://$host:43443/remote.php/dav;
    }

    location ^~ /.well-known/caldav {
        return 301 $scheme://$host:43443/remote.php/dav;
    }

    location = /.well-known/webfinger   {
         return 301 $scheme://$host:43443/index.php$uri;
    }

    location = /.well-known/nodeinfo   {
         return 301 $scheme://$host:43443/index.php$uri;
    }

    location ~ /\.well-known/acme-challenge {
        allow all;
    }

    error_page 403 /core/templates/403.php;
    error_page 404 /core/templates/404.php;

    # set max upload size 
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Disable gzip to avoid the removal of the ETag header 
    gzip off;


    location / {
        rewrite ^ /index.php;
        set $memcached_key $uri;
        memcached_pass localhost:11211;
        memcached_connect_timeout 200ms;
        memcached_read_timeout 200ms;
    }

    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
        deny all;
    }

    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;
    }

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
        include fastcgi_params;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        try_files $fastcgi_script_name =404;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        #Avoid sending the security headers twice 
        fastcgi_param modHeadersAvailable true;
        fastcgi_param front_controller_active true;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_intercept_errors off;
        fastcgi_request_buffering off;
        include snippets/fastcgi-php.conf;
    }

    location ~ ^/(?:updater|ocs-provider)(?:$|/) {
        try_files $uri/ =404;
        index index.php;
    }

    # Adding the cache control header for js and css files 
    # Make sure it is BELOW the PHP block 
    location ~* \.(?:css|js)$ {
        try_files $uri /index.php$uri$is_args$args;
        add_header Cache-Control "public, max-age=7200";
        # Add headers to serve security related headers (It is intended to 
        # have those duplicated to the ones above)
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag "noindex, nofollow";
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header Referrer-Policy no-referrer;
        # Optional: Don't log access to assets 
        access_log off;
    }

    location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
        try_files $uri /index.php$uri$is_args$args;
        # Optional: Don't log access to other assets 
        access_log off;
    }

    location ~* \.woff2$ {
        add_header Access-Control-Allow-Origin *;
        expires 30d;
        access_log off;
        add_header Cache-Control "public";
    }

    location ~ \.mjs$ {
        try_files $uri /index.php$request_uri;
        default_type text/javascript;
        add_header Cache-Control "public, max-age=15778463";
        access_log off;
    }
}

There you have my configuration mate, don’t forget cache memory can show the issue even when it is not happening.

4

It seems to have fixed itself for me too, I just updated to v29 so I guess they finally got around to fixing it recently. Which is funny because I’ve had the issue and complained about it on github since around v23, so just as I decide to post again about it they release a fix.

Well it’s nice to finally have a green checkmark on the admin dashboard, and anyone coming across this thread hopefully gets some good examples on how to get it to work.

5

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.