[solved] .well-known/caldav check in 15.0.4 nextcloud sever is behind an HAproxy where SSL-offloading is being performed

I had this issue and followed all the tutorials online with no success.

I’m using HAProxy for SSL offloading with let’s encrypt. So the internal traffic from HAproxy to nextcloud server is HTTP.

The below solution solved it for me:

navigate to:
root@nextcloud:/etc/apache2/sites-available# nano 000-default.conf

#below the Virtualhost closing remark </VirtualHost…
#add these two lines

Redirect 301 /.well-known/carddav https://cloud.example.com/remote.php/dav
Redirect 301 /.well-known/caldav https://cloud.example.com/remote.php/dav

save and restart apache2

Done! :wink:

Hope these help out someone … I fort for days to get this working…

3 Likes

Could you perhaps please post the whole 000-default.conf file? I am using your settings, we have the same setup and thus the same issue, and adding these lines as you indicated, does not work for me.

Hi Starfish,

There you go!

<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request’s Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf

</VirtualHos…>
Redirect 301 /.well-known/carddav https://cloud.hostname.net/remote.php/dav
Redirect 301 /.well-known/caldav https://cloud.hostname.net/remote.php/dav

Thanks @DarkWeb

We have ours set up like this, but when we click on the Settings>Administration>Overview, it gives us internal server error.

<VirtualHost *:81>
     DocumentRoot /var/www/html/nextcloud
     ErrorLog logs/oc-error_log
     CustomLog logs/oc-access_log common
     <IfModule mod_headers.c>
       Header set Strict-Transport-Security "max-age=15768000"
     </IfModule>
    <Directory /var/www/html/nextcloud>
     Options Indexes FollowSymlinks
     AllowOverride All
     Order allow,deny
     Allow from all
     DirectoryIndex /var/www/html/nextcloud
    </Directory>
     #Alias "/nextcloud"  "/var/www/html/nextcloud"
     Redirect 301 /.well-known/carddav https://nextcloudtest.our-domain.com/remote.php/dav
     Redirect 301 /.well-known/caldav https://nextcloudtest.our-domain.com/remote.php/dav
</VirtualHost>

Any ideas?

seems like you are placing it on the wrong file.
in sites-available directory, there should be 3 files
root@nextcloud:/etc/apache2/sites-available# ls
000-default.conf
nextcloudtest.our-domain.com.conf
default-ssl.conf

edit the 000-default.conf as mentioned above…

removed the redirect statement you made on the main sites file (nextcloudtest.our-domain.com.conf)

seems like you are placing it on the wrong file.
in sites-available directory, there should be 3 files
root@nextcloud:/etc/apache2/sites-available# ls
000-default.conf
nextcloudtest.our-domain.com.conf
default-ssl.conf

edit the 000-default.conf as mentioned above…

removed the redirect statements you made on the main sites file (nextcloudtest.our-domain.com.conf)

Sorry, forgot to mention this is on CentOS, so it lives in /etc/httpd/conf.d/nextcloud.conf. And whether we put it inside or outside of the </Virtualhost> stanza it makes no difference.

Ahh got that. Mine is running on Debian 9
Do you have the 000-defailt.conf file in your setup?

Just the basic /etc/httpd/conf/httpd.conf, but nothing in there that would break only that specific page in NC. No redirects or anything like that.

Not sure if there is a difference in Apache interpretation between Debian and CentOS.

Yeah… that might be the case…

try to place it in .htaccess file let’s see…

try placing it here also:

/etc/httpd/conf.d/ssl-params.conf

Hi, I was wondering if you knew a solution for this on nginx? I’ve seen various threads listing this solution for apache, and from them I gathered that I needed to adding the following lines to my etc/nginx/sites-enabled/cloud.jackalope.tech configuration"

location = /.well-known/carddav {
        return 301 https://$host/remote.php/dav;
    }

    location = /.well-known/caldav {
        return 301 https://$host/remote.php/dav;
    }

Also in the process of searching for this I have actually found a file with much more settings information in it under etc/nginx/conf.d/nextcloud.conf

This place even has a section in it for the:

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

Which is making me think this is the proper config location. But then why do I have a file under sites-enabled? Does that need to be symlinked to the conf.d file maybe?

Here’s the forum thread I’m logging my progress and working through stuff.

On ubuntu / apache / I don’t have 000-default enabled so I put the two lines in sites-available/nextcloud.conf and it worked fine
Thanks Darkweb

Ubuntu 18.04 Apache2 Nextcloud 26.

After hours, this solution (000-default.conf) did work.

Thanks again @DarkWeb

FYI : I added Redirect 301 /.well-known/nodeinfo https://myNCDomain/index.php/.well-known/nodeinfo.
It looks like working. Not the case for webfingers