HELP with SSL Certificate

Hello all.

Ive done my Collabora Server via Docker on my NAS and I having problems with the SSL certificate.

The main domain recognize the SSL certificate just fine and the Nextcloud goes without any problem, but when I try to connect to the port of the collabora server ( In the same domain + :PORT ) it doesnt see the correct certificate anymore. Shows as DUMMY AUTHORITY and doesnt allows my Nextcloud, neither my browser to connect into it ( it doesn’t even give the option to proceed ). I can connect to via PUBLIC IP, but that doesnt have SSL certificate on it but at least gives the option to proceed in the browser and connects on the Nextcloud.
But I would like to have my SSL certificate working on the port of the Collabora Server just like it works in the main domain.

Any Idea where am I failing?

hii @Cayan-321

This is a very common and understandable point of confusion when setting up Collabora with Docker.

Let’s break down why it’s happening and how to fix it.

  • The Core Problem: Who is Handling the SSL?
  1. https://yourdomain.com (Nextcloud): When you access this, you are connecting to a reverse proxy (like Nginx, Apache, Caddy, or Traefik) on the standard HTTPS port 443. This proxy is correctly configured with your SSL certificate. It handles the encryption and then forwards your request internally to your Nextcloud container. The browser only ever talks to the proxy, so the SSL is valid.

  2. https://yourdomain.com:9980 (Collabora): When you access this, you are bypassing the reverse proxy entirely. You are connecting directly to the Collabora container on its specific port (9980).

The “DUMMY AUTHORITY” certificate you’re seeing is the default, self-signed certificate that comes built into the Collabora Online Development Edition (CODE) Docker image. It’s a placeholder, and browsers correctly reject it because it’s not signed by a trusted authority.

The Solution: Let Your Reverse Proxy Do the Work

The best-practice and most secure solution is to not expose Collabora’s port (9980) to the internet. Instead, you should configure your reverse proxy to handle requests for Collabora, just like it does for Nextcloud.

This involves three main steps:

  1. Create a new subdomain for Collabora (e.g., office.yourdomain.com).
  2. Configure your reverse proxy to listen on that subdomain and forward traffic to the Collabora container.
  3. Tell Collabora that it’s sitting behind a proxy and that it should not handle SSL itself.

Recommended Method: Using a Reverse Proxy

This is the standard and most robust way to set this up.

Step 1: DNS Setup

Go to your domain registrar or DNS provider and create a new A record or CNAME record for a subdomain. For example:

  • Type: A
  • Name/Host: office (or collabora, docs, etc.)
  • Value/Points to: Your NAS’s public IP address.

Now, office.yourdomain.com will point to your server.

Step 2: Reverse Proxy Configuration

You need to add a new virtual host/proxy configuration that listens for office.yourdomain.com and forwards it to your Collabora container.

Here are examples for common proxies. You only need to do one of these.

If you use Nginx Proxy Manager (very common on NAS setups):

  1. Log in to Nginx Proxy Manager.
  2. Go to Hosts → Proxy Hosts and click Add Proxy Host.
  3. Details Tab:
    • Domain Names: office.yourdomain.com
    • Scheme: http
    • Forward Hostname / IP: Your NAS’s local IP address (e.g., 192.168.1.10).
    • Forward Port: 9980
    • Enable Websockets Support: This is CRITICAL for Collabora to function.
  4. SSL Tab:
    • SSL Certificate: Select “Request a new SSL Certificate”.
    • Enable “Force SSL” and “HTTP/2 Support”.
  5. Click Save.

If you use a manual Nginx configuration file:

Add a new server block to your Nginx configuration. It should look something like this:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name office.yourdomain.com;

    # SSL configuration
    ssl_certificate /path/to/your/fullchain.pem;
    ssl_certificate_key /path/to/your/privkey.pem;
    # Add other SSL hardening options here

    # Log files
    access_log /var/log/nginx/collabora.access.log;
    error_log /var/log/nginx/collabora.error.log;

    # WebSocket support - VERY IMPORTANT
    location / {
        proxy_pass http://127.0.0.1:9980; # Use your NAS IP if not on the same machine
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Step 3: Reconfigure Your Collabora Docker Container

Now you must tell your Collabora container to disable its internal SSL because the reverse proxy is handling it. You do this by adding an environment variable to your docker run or docker-compose.yml file.

The key is to add this parameter: --o:ssl.enable=false

Using docker-compose.yml:

services:
  collabora:
    image: collabora/code:latest
    container_name: collabora
    ports:
      - "127.0.0.1:9980:9980" # Only expose to the host, not the world
    environment:
      - domain=nextcloud\\.yourdomain\\.com # Your Nextcloud domain
      # This is the crucial part!
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
    restart: always
    # ... other configs

Using docker run:

You would add this to your command: -e "extra_params=--o:ssl.enable=false --o:ssl.termination=true"

After making this change, you need to restart your Collabora container.

Step 4: Update Nextcloud Settings

  1. In Nextcloud, go to Administration settings → Nextcloud Office.
  2. Select “Use your own server”.
  3. In the URL field, enter the new reverse-proxied URL: https://office.yourdomain.com (with no port number).
  4. Click Save.

It should now connect successfully, and your entire setup will be running securely behind your reverse proxy.

This method is more secure, easier to manage (you only handle SSL certs in one place), and uses standard, clean URLs without port numbers.

Thanks
Darshan

Wow, thank you so much for all the help! Thats Amazing.

Now, Im on a QNAP, and I cant create subdomains… what would be the best option here?

Thank you for everything so far !

that DUMMY AUTHORITY cert is collabora serving its own self-signed cert because it never got told ssl is being handled elsewhere. the cleanest fix is to stop trying to put a cert on the collabora port directly and instead terminate ssl at a reverse proxy, then run the container with --o:ssl.enable=false --o:ssl.termination=true (and DONT_GEN_SSL_CERT=true so it doesnt keep regenerating that dummy one). nextcloud then talks to the proxy over https, the proxy talks to collabora over plain http on the internal port, and the browser only ever sees your real cert.

on qnap the subdomain thing is the real blocker. you dont actually need a separate office.yourdomain.com if you proxy by path instead. point nextcloud at https://yourdomain.com and have the reverse proxy route the collabora paths (/browser, /hosting, /cool, /lool) to the container. qnap ships with its own web server though so the built in reverse proxy can be fiddly, and a lot of people just spin up an nginx proxy manager container to get a clean cert + routing without fighting the appliance ui. if you go that route make sure websockets are enabled on the proxy or you’ll get docs that load halfway then hang.

honestly if wrestling the qnap proxy and cert plumbing gets old, theres a few self-hosting platforms that just bundle nextcloud + collabora and do the https and reverse proxy for you. full disclosure im involved in one called syncloud, it does one-click installs of both and handles the certs automatically, so its an option if you’d rather not hand-roll the proxy config. either way the path-based proxy with ssl.termination should sort the dummy cert problem.