mTLS Support

[scndr]

Environment / Setup

• App: OpenCloud running in Docker
• Reverse Proxy: Traefik v3 (handling SSL termination and client authentication)
• Authentication: Mutual TLS (mTLS) with clientAuthType: RequireAndVerifyClientCert enabled on the main HTTPS entrypoint (websecure).

Problem Description

I am running OpenCloud behind an external Traefik reverse proxy configured with mTLS (RequireAndVerifyClientCert) for public endpoints.

While browsing the web UI, navigating folders, and performing general actions work seamlessly (since the browser/client sends the required TLS client certificate), file uploads fail with HTTP status 500.

Technical Analysis

Looking into the logs, when a file upload is initiated, the OpenCloud frontend service attempts an internal loopback PATCH request to the public Data Gateway URL (https://cloud.MYDOMAIN.xyz/data/...).

Because this request originates internally from the container/microservice itself, it does not present the required mTLS client certificate to Traefik. As a result, Traefik rejects the loopback request with a tls: certificate required error, causing the frontend service to crash the upload with an HTTP 500 error.

Anyone has tried to configure the mTLS with OpenCloud?

Relevant Logs

Traefik Access Log:

{
  "ClientAddr": "192.168.1.7:58811",
  "DownstreamStatus": 500,
  "OriginStatus": 500,
  "RequestMethod": "POST",
  "RequestPath": "/dav/spaces/f123............88",
  "RouterName": "opencloud@docker",
  "ServiceAddr": "172.18.0.21:9200",
  "TLSClientSubject": "CN=XXXXXXX",
  "TLSVersion": "1.3"
}

[KeuqS]

This looks like a server-to-server URL problem rather than a browser mTLS problem. The browser presents the client certificate, but the internal frontend/container call to the public data gateway does not, so Traefik rejects the loopback request with tls: certificate required before the upload can complete.

A practical setup is:

1. Keep the public hostname (for example, cloud.MYDOMAIN.xyz) on the Traefik entrypoint that requires mTLS.
2. Provide a separate internal hostname or entrypoint for OpenCloud-to-OpenCloud traffic on the Docker/private network, without client-certificate authentication (server TLS can still be enabled).
3. Make the internal container resolve the data-gateway hostname to that private route using split-horizon DNS or an internal Docker DNS alias. Do not expose that route publicly.
4. Keep OC_URL/FRONTEND_PUBLIC_URL set to the public URL, because those values are used for user-facing links. OCM_OCM_STORAGE_DATA_SERVER_URL is for the OCM storage service and is not a general fix for the main file-upload path.

Also check the OpenCloud version before changing the proxy. OpenCloud tracked the same external data-gateway callback pattern in #2860, including TUS PATCH requests being sent to the external data-gateway URL; that issue is marked done. If you are on an older release, upgrade to a current release first and retest. The frontend URL settings are documented here.

[scndr]

thanks! i moved to LTS to Rolling release (7.2.4 -> 8.1.0) and works fine.