.well-known/webfinger isn't properly set up! Docker issue perhaps?

[graffen]

I run my Nextcloud instances in Docker behind a reverse proxy (jwilder/nginx-proxy). One of my instances is running the fpm version of the Nextcloud Docker image and the other is running the Apache version.

When I try to access the Social app on both my instances I get

.well-known/webfinger isn't properly set up!

Social needs the .well-known automatic discovery to be properly set up. If Nextcloud is not installed in the root of the domain, it is often the case that Nextcloud can't configure this automatically. To use Social, the admin of this Nextcloud instance needs to manually configure the .well-known redirects: 

I have checked that all redirects function as they should, i.e. I can access /.well-known/webfinger?resource=acct:<my federation id> and get the basic account details returned as would be expected.

I have tried different permutations of setting the overwrite.client..url setting in my Nextcloud config.php file but that doesn't seem to change anything. I suspect that this may have something to do with my instances running behind reverse proxies and not being able to do their own self-assessment for some reason but other than that I don't know where to look.

Any help would be much appreciated.

[juliusknorr]

Could it be that the docker nextcloud instance cannot reach the public url that is configured in overwrite.cli.url? Can you try to call the webfinger from the nextcloud docker container with curl https://your.cli.url/.well-known/webfinger?resource=acct:myfedid

[ghost]

@juliushaertl I think you're onto something. I get connection refused. My knee-jerk reaction was just to replace that setting with http://localhost/ but that means all URLs in the resulting json are wrong.

I'm guessing this configuration of running behind an SSL-offloading proxy isn't supported yet then. If I set something else in overwrite.cli.url that will just be used everywhere the Social app needs to reference its own URL and will make outside connections fail instead.

[ghost]

Hmm I got the message to disappear after playing around with overwrite.cli.url and overwriteprotocol. At least the message is gone now after switching things back and forth a bit.

[ghost]

Now it's back... seems a bit random...

[sjoerger]

I was having the same issue and using the curl example above it worked from my desktop but not from my Nextcloud server. The error I received from curl was "curl: (60) SSL certificate problem: unable to get local issuer certificate".

I use a Let's Encrypt certificate on my webserver. Adding a Let's Encrypt intermediate CA cert to my certificate store resolve the issue for both curl and the error displayed in the Social application.

[ghost]

Because my Nextcloud is running in Docker SSL is not available from inside the container. So that part will never work in my setup. Perhaps the webfinger check could be rewritten to fall back to testing on port 80 if 443 fails. Would that work?

[juliusknorr]

No, that won't work as with this check we also need to be sure there is a valid SSL certificate in order to make sure that social works. But we can move the check to the client side as mentioned above.

[gloomytrousers]

I have what I think is a similar issue, running nextcloud:fpm, behind Apache running on the host. The cause seems to be that the container can't access the host's Apache:

root@331a5bca0d59:/var/www/html# curl https://cloud.example.com/.well-known/webfinger?resource=acct:[email protected]
curl: (7) Failed to connect to cloud.example.com port 443: No route to host

I've tried passing --network=host to the docker run, which should allow the container to access the host network, but then the container won't start as it can't bind to the right port (which is in use on the host for another purpose), and anyway I gather it's not really considered good security practice.

The .well-known URL works correctly from everywhere else.

[KopfKrieg]

FYI: I'm running nextcloud 15 in a docker container, behind a proxy which manages SSL through Let's Encrypt. Everything's running fine so far, --network=host is not necessary (my proxy and the nextcloud container are part of the same docker network).

As @graffen mentioned, make sure to set overwrite.cli.url and overwriteprotocol in your config.php like this:

[…]
'overwrite.cli.url' => 'https://example.org',
'overwriteprotocol' => 'https',
[…]

Also, your proxy needs to rewrite the request like this (same for the apache image and the fpm version!):

# Social app
rewrite {
    r ^/\.well-known/webfinger$
    to /public.php?service=webfinger&{query}
}

And I'm not sure on this one, but maybe it needs to rewrite host-meta and host-meta.json too:

# User_webfinger app
rewrite {
    r ^/\.well-known/host-meta$
    to /public.php?service=host-meta&{query}
}
rewrite {
    r ^/\.well-known/host-meta\.json$
    to /public.php?service=host-meta-json&{query}
}

If your nextcloud is accessible through a path (like https://example.org/nextcloud ) make sure that the rewrite takes that into account! And don't forget that the .well-known directory needs to be in the root location, not behind a path (NOT https://example.org/nextcloud/.well-known but https://example.org/.well-known ).

Also, the following requests should work:

curl -H "Accept: application/ld+json" -X GET https://example.org/apps/social/@Username
curl https://example.org/.well-known/webfinger?resource=acct:[email protected]

[didyouexpectthat]

I use Nextcloud 20 on Proxmox. Noticed this problem today. I use LXC container and have a dedicated IP address locally, but I use HAproxy with LetsEncrypt certificate to access from WAN/LAN. I noticed above and experienced curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number ; it only happened on the nextcloud container, not on other clients. My network DNS points nextcloud.domain.tld to my proxy IP, but the container itself was the same nextcloud.domain.tld. Ping was returning the container IP. I changed the container fqdn to nextcloud.internal.domain.tld and now it returns the proxy and removed both the SSL error as well as the webfinger not being properly configured,