NS8 / well-known redirections (for Nextcloud or other apps)

Bug
,
1

Nextcloud .well-known redirects return http:// instead of https://

The .well-known/caldav and .well-known/carddav redirects on my NS8 Nextcloud instance return a Location header with http:// instead of https://, which causes iOS/macOS mobileconfig profile installation to fail (DAAccountValidationDomain error 100 / CoreDAV 405).

Curl confirms it:

curl -v https://drive.example.com/.well-known/caldav
< HTTP/2 301
< location: http://drive.example.com/remote.php/dav/

The fix looks straightforward — the redirect target just needs https:// — but I’m not sure of the right place to make this change in NS8 without it being overwritten on the next module update. Maybe it’s something related to Traefik though ?

What’s the recommended approach? A custom nginx snippet somewhere in the module directory, an environment variable, or something else?

–

More broadly, a UI setting to configure .well-known redirect targets would be a nice addition. The right destination depends on the specific setup: CalDAV/CardDAV might be served by Nextcloud on one instance, SOGo on another, or even an external server entirely. Having that configurable from the interface rather than requiring manual nginx edits would make NS8 more flexible for real-world deployments.

2

small bump to ensure this doesn’t get forgotten :slight_smile:

3

Redirecting to https:// is certainly reasonable. The redirect may be generated either by the Nextcloud Nginx container or by Traefik itself, so it would be worth digging a bit deeper to identify where the Location header is being built before deciding on the fix.

Regarding the broader .well-known configuration idea, I’m not sure it fits well with the current NS8 architecture. In most deployments, services such as Nextcloud and SOGo are exposed on distinct domains, and each application is expected to handle its own .well-known endpoints for that domain. Having a central UI to route .well-known requests across unrelated applications could introduce ambiguity. That said, I may be missing some real-world scenarios where such flexibility would be useful.

4

You’re completely right, please discard this.

Could you give some pointers ? I’ll have a look.

Txs !

1 Like
5

Thank you for the help!

I changed category to Bug because this redirect is unsafe. I think the header is generated by Nextcloud application and the fix should go there. Traefik does http->https redirection only if TLS is missing, it does not alter the app’s response.

Could you paste the complete curl -v output (without cookies/auth tokens, if any)?

6

Sure, thanks.

# curl -v https://drive.domain.tld/.well-known/caldav
*   Trying 168.119.140.230:443...
* Connected to drive.domain.tld () port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=drive.domain.tld
*  start date: May 20 21:01:40 2026 GMT
*  expire date: Aug 18 21:01:39 2026 GMT
*  subjectAltName: host "drive.domain.tld" matched cert's "drive.domain.tld"
*  issuer: C=US; O=Let's Encrypt; CN=R12
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET /.well-known/caldav HTTP/1.1
> Host: drive.domain.tld
> User-Agent: curl/7.76.1
> Accept: */*
> 
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Unknown (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.26.1
< Date: Tue, 16 Jun 2026 12:58:16 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: http://drive.domain.tld/remote.php/dav/
< Referrer-Policy: no-referrer
< 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
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host drive.ldomain.tld left intact
1 Like
7

Filed a new bug here Nextcloud .well-known redirects downgrade HTTPS to HTTP · Issue #8043 · NethServer/dev · GitHub

2 Likes