AIO, collabora, and separate caddy with mTLS client authentication

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • Nextcloud 31.0.5 (AIO v10.15.0)
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04.2 LTS
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • caddy v2.10.0 h1 (standalone)
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • Since installation
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AlO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary:

Is it possible to use the nextcloud AIO docker container, with a separate caddy reverse proxy and mTLS client authentication?

When performing the domain validation on the AIO interface, I had to disable client authentication. Once the containers have been downloaded and started, if I try to re-enable TLS client authentication in caddy I get errors when trying to open documents for editing with collabora. I’ve tried fiddling with collabora server settings but just wondering if this is feasible at all, or I am going to run into further issues.

Troubleshooting I have attemped

  1. Set up AIO with client authentication disabled (to pass domain check)
  2. Enable caddy client authentication
  3. Open example .docx document
  4. Get “Unauthorised WOPI host.” error

I have tried following debugging suggestions here: all-in-one/reverse-proxy.md at main · nextcloud/all-in-one · GitHub and here: How to debug problems with Collabora and/or Talk · nextcloud/all-in-one · Discussion #1358 · GitHub

In particular, settings/admin/richdocuments shows

Failed to connect to the remote server: cURL error 56: OpenSSL SSL_read: OpenSSL/3.3.3: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)

Changing the “URL (and Port) of Collabora Online-server” to my server’s IP and port does fix this error (i.e. it says “Collabora Online server is reachable), but still results in the same error when loading a document. I also tried adding " ,0.0.0.0/0” to the “Allow list for WOPI requests”, to no effect.

Apologies if I’ve just missed this elsewhere

Log entries

Nextcloud

RequestException cURL error 56: OpenSSL SSL_read: OpenSSL/3.3.3: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://my.domain/hosting/discovery

RequestException cURL error 56: OpenSSL SSL_read: OpenSSL/3.3.3: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://my.domain/cool/convert-to/png

Web server / Reverse Proxy

With mTLS enabled, my caddyfile looks like:

(client_auth_setting) {
  tls {
    client_auth {
      mode require_and_verify
      trust_pool file {
        pem_file ca.crt
      }
    }
  }
}

nextcloud.my.domain {
  import client_auth_setting
  reverse_proxy 192.168.1.100:11000
}

This is a bare metal caddy installation on the same device. mTLS works fine for other applications so I don’t think that set up is an issue.

I have tried searching for other people with this issue, but not found anything directly relevant. I appreciate the answer may just be that using client authentication with the AIO container may not be possible, apologies if so but would be good to know for sure!

Configuration

The result of running curl -vvv https://$NC_DOMAIN:443/hosting/discovery in the container is ultimately

curl: (56) OpenSSL SSL_read: OpenSSL/3.3.3: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0

Hi, see Nextcloud AIO can't reach Collabora because of TLS client certificate · nextcloud/all-in-one · Discussion #6161 · GitHub

Thanks, I had missed this question, will give it a go, but looks like they have only found part of the solution so far.

I was (naively) hoping there might be a simple way to just get the AIO sub-containers to talk to each other using local addresses, without relying on the external domain.

this is hard to implement this and I don’t think somebody would add such “internal communication” as it makes the setup much more complex without any advantage.

1 Like

I’m interested by this reply. I’ll fully admit to not understanding exactly what the AIO container is doing, but in my uninformed mind the default would be for “inter-container” communication to use local/internal addressing rather than relying on the external domain.
Not that I was asking anyone to implement anything, just hoping I might have missed some configuration options. I can also think of at least one advantage!

Either way, the answer seems to be a rather firm no!

this is the case for connections to database and redis but WOPI protocol used for office integration like Collabora or OnlyOffice is completely different story it requires TLS and for this reason public domain (see background information from Collabora integration guide). yes it is possible to trick public fqdn connections to remain local and connect to internal IPs using splitbraindns but this still doesn’t help you with mTLS auth.

1 Like

Thanks, this makes it clearer to me