Docker: Service discover doesn't work behind reverse proxy

[funkypenguin]

Hey guys,

I'm using NextCloud docker image behind a Traefik SSL-terminating reverse proxy. I found I was unable to use service discovery to configure CalDAV/CardDAV on my iOS device, because the 301 redirect served by https://MYHOST/.well-known/caldav is an http URL (http://MYHOST/remote.php/dav), since the container has no native HTTPS setup.

I've temporarily worked around this by changing the following in .htaccess:

RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]

To:

RewriteRule ^\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]

But I imagine this is not an ideal fix, since .htaccess could be automatically updated during upgrades / app installs.

Can we have a config.php option, tied to the occ maintenance:update:htaccess process, which would automatically insert the necessary https elements to ensure service discovery works? Perhaps something like overwrite.redirect.url = https://MYHOST?

Notes:

1. Issue #528 is related
2. I've written a more detailed description of the fix here: https://geek-cookbook.funkypenguin.co.nz/recipes/nextcloud/#use-service-discovery

Thanks!
D

[kesselb]

I guess you have to adjust some of these values? but i'm not sure if these are considered for the well-known redirect.

https://docs.nextcloud.com/server/15/admin_manual/configuration_server/reverse_proxy_configuration.html

[J0WI]

I think this could be fixed by #527

[kesselb]

I dont use traefik but if i would go for this solution. Let traefik return the right url sounds like a better way to do it.

traefik.frontend.redirect.permanent: 'true'
traefik.frontend.redirect.regex: https://(.*)/.well-known/(card|cal)dav
traefik.frontend.redirect.replacement: https://$$1/remote.php/dav/

https://github.com/nextcloud/server/issues/11850#issuecomment-443419867 all credits to @pauvos

[zroug]

527 won't fix the issue. (Maybe it is a Nextcloud bug, that it doesn't?)

I think the correct way to fix the issue without a change to Nextcloud is to add these lines

ServerName https://cloud.example.com
ServerAlias *
UseCanonicalName On

inside of <VirtualHost> in /etc/apache2/sites-available/000-default.conf. cloud.example.com is your host name and https is your protocol.

UseCanonicalName On tells Apache to use ServerName for rewrites. ServerAlias * is not strictly necessary, but it makes the intention clear, that this virtual host should accept all connections.

This will work for all rewrites that Nextcloud adds in the future. One could make it configurable using the same variables used in #527.

[SysEngDan]

The suggested fix by the OP worked for me. I'm running NC 15.02 container behind an Nginx reverse proxy.

[marceljd]

See #644, it is possible to fix this with changes in the proxy settings, but running Nextcloud Apache on https is the better way.

[zroug]

While #644 can solve the issue, it requires to use an additional layer of encryption in a perfectly trusted network. My solution https://github.com/nextcloud/docker/issues/577#issuecomment-447571320 can tell Apache from where it is accessed on the public network, without the need to access it the same way on the internal network. This solution also doesn't require any changes to the proxy settings or Nextcloud itself.

[marceljd]

@zroug I did not see your solution untill now. I am not an Apache expert, but your solution would mean that all traffic is still unencrypted behind a proxy or not (since the port used is still 80 and the Apache SSL engine is off)? I agree that adding the servername with the real (external) hostname does add some security. The best solution would be to give the proxy the certificates of the Apache instance and let Apache only accept the connections to the servername that should be set to the external address. Or do I miss something?

The second question I have: would it still be possible to access the server by IP address for users who only need intranet access and do not have internal DNS set up?

@J0WI @tilosp @SnowMB what do you think? I'd be happy to build this into the PR (#644 ) if everyone thinks that this will be the better solution (or perhaps use both and add the server-name as an environment variable?).

edit: though the internal network in Docker or Kubernetes is fairly trustable, someone could break out of another container and sniff around. I would not consider an internal network as perfectly trusted. Adding SSL for the internal traffic is not a bad thing to my opinion.

[zroug]

Yes that would mean that Apache is still on port 80 and Nextcloud is still accessible from internal ips. It has only an effect on some links, like share links or the dav redirect. Therefore I suggest to integrate that with #527 because that would make it explicit that it is the behavior that you want.

I certainly think that #644 is a good thing and some additional security dosen't hurt, but it solves a different issue. Sometimes you want to solve this issue independently.

For example: Traefik still has some issues with self signed certificates. That can make it difficult to use self signed certificates. You suggested to set insecureSkipVerify: true but that would mean that not much security is added because the certificate is not validated and more importantly it means you also skip verification for backends where you want to verify the certificate.

[marceljd]

OK, thnx for the explanation. I do not think both use cases can be solved at once. Besides that it is impossible to solve several upstream issues like all different Traefik discussions about encrypting traffic to the backends. I am aware of those but in general I think it is good to stick to standardized solutions as much as possible for mainstream applications and patching on different locations often leads to other problems in the future.

Based on this discussion I think it would be wise to implement a second environment variable in #644 that handles the redirect from http to https. The main goal should be to let the client container generate certificates and run on SSL with a default self signed certificate, but redirection is a seperate decision to make, or should at least have an option to disable it. Activating SSL will solve most issues of the security checks but it has certain restrictions. If you do not want or cannot enable SSL, you do not set the environment variable and nothing will change.

For #527 and #577 the goal should be to patch the server for various issues without activating SSL for those who need it, but I think the general advice should be to activate SSL where possible and let Nextcloud do the configuration-magic it normally does.

[SysEngDan]

I think the proper resolution is to treat this issue, #577, as an improvement to NextCloud for reverse proxy support. I believe that most instances where this is being used for a professional use, it is located behind a reverse proxy, whether that's Trafik or Nginx, and the protocol between Trafik and the Apache hosted container is HTTP.

[ffried]

For those that have control over the reverse proxy (e.g. an apache 2), the following config lines can fix the issue inside the proxy (as a workaround):

RewriteEngine On
RewriteRule ^/\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]

[GuyPaddock]

I just posted a comment about another option for those using NextCloud on NGinx (even if you are not using NGinx for the proxy): https://github.com/nextcloud/docker/pull/527#issuecomment-469474365

[kesselb]

I prepared a pull request for the documentation. Could you share your solutions? https://github.com/nextcloud/documentation/pull/1297

[SnowMB]

Thanks @kesselb for pointing that out. #528 and #635 had the same problem.