Am I misunderstanding ssl.termination and the discovery endpoint?

Installation & Configuration
1

I have the following set as the “extra_params” environment variable:

--o:ssl.enable=false --o:ssl.termination=true

I have a reverse proxy that accepts a https ssl connection which then it proxies a http request to my collabora/code container.

However, when I browse to https://office.my.domain/hosting/discovery all of the urls in the response start with http, not https (other than that they seem correct).

My nextcloud instance is using the http URL from the discovery doc. The only way I’ve managed to get the discovery XML to contain https links is by setting ssl.enable to true.

Is this a bug or am I not understanding the discovery doc?

2

hii @connelhooley

What you’re seeing is expected behavior, not a bug.

Collabora’s discovery document reflects what Collabora thinks its own base URL is, based on how it was started:

  • --o:ssl.enable=true → CODE itself terminates TLS, so it generates https://… URLs.
  • --o:ssl.enable=false --o:ssl.termination=true → CODE assumes TLS is terminated before it (at a reverse proxy) and it only sees plain HTTP internally, so it generates http://… URLs.

That’s why your /hosting/discovery response shows http:// links in the second case.

For setups with a TLS-terminating reverse proxy, the important part is not the discovery XML, but how your proxy is configured. The discovery URLs don’t need to match what CODE thinks internally, they just need to work correctly when passed to the client (Nextcloud). If Nextcloud consumes those http:// URLs, it will try to reach CODE directly over plain HTTP — which fails if your proxy only exposes HTTPS.

solutions:

  1. Force HTTPS in proxy: Make sure your reverse proxy rewrites the scheme so that externally only https://office.my.domain/... is reachable, regardless of what the XML says.
  2. Use --o:ssl.enable=true: Let CODE generate https:// URLs directly. This works if your proxy just passes through TLS traffic (or if you terminate TLS twice, which isn’t harmful but sometimes redundant).
  3. Set --o:ssl.termination=true and adjust headers: Ensure your proxy is setting X-Forwarded-Proto: https. CODE will then honor that and generate https:// links in discovery, even though it itself only talks plain HTTP.

So the key is: with --o:ssl.enable=false --o:ssl.termination=true, you must have your proxy send X-Forwarded-Proto: https. Otherwise, CODE assumes clients will connect via HTTP and writes http:// in the discovery doc.

3

Thank you spending the time to explain this to me. I tried to manually set the X-Forwarded-Proto header in my reverse proxy (Caddy) but I got the same behavior. I’ve stuck with the option where I ignore the self signed cert in Caddy for now.

What is the use-case when a user would have for ssl.termination set to true whilst wanting the http protocol in the discovery document?

This seems inconsistent with “server_name”. Taken from the docs:

If the reverse proxy is not preserving the Collabora Online host name, it has to be set in server_name setting.

If the reverse proxy doesn’t preserve the host name we can easily fix this, but with the protocol we can’t. The importance of the X-Forwarded-Proto header wasn’t in the docs that I’ve read regarding reverse proxies too.

4
  • ssl.enable=true → CODE does TLS itself → discovery shows https://.
  • ssl.enable=false --o:ssl.termination=true → TLS expected at proxy → CODE trusts X-Forwarded-Proto.
  • If X-Forwarded-Proto: https is missing, discovery shows http://.
  • Use-case for plain http://: internal/no-TLS setups where Nextcloud also talks HTTP.
  • server_name overrides host; there’s no equivalent for scheme — protocol override relies only on X-Forwarded-Proto.

I am not expert on caddy config’s

I’m not too sure about the Caddy side of things you might find a working example in their docs or by asking in their public channel. From what I can tell, the issue looks more like a Caddy configuration problem than a Collabora one.

1 Like