Am I misunderstanding ssl.termination and the discovery endpoint?

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.