Custom root certificates¶

By default, Seatable uses Let's Encrypt to generate valid certificates for public access. However, Caddy also provides an easy way to use custom certificates. This section assumes that you intend to use a valid (standard or wildcard) certificate issued by a widely trusted certificate authority.

Limitations of Self-Signed Certificates

Self-signed certificates should only be used for testing purposes. Even if your clients or browsers trust the certificate, Docker containers do not trust each other by default.
As a result, the Python Runner will be unable to communicate with your Base data, and the Python Pipeline will not work with an untrusted self-signed certificate.

To avoid these issues, use a valid (standard or wildcard) certificate issued by a recognized certificate authority.

Make certificates available to caddy¶

With the caddy.yml a default volume-mount is created: /opt/caddy:/data/caddy By convention you should provide your certificate & key files in the container host filesystem under /opt/caddy/certs/ to make it available to caddy.

In the article, we assume that your certificates were saved as cert.pem and key.pem.

/opt/caddy/certs/
├── cert.pem
├── key.pem

Command to generate custom certificates

With this command, you can generate your own custom certificates. Please be aware that custom certificates can not be used for ip-addresses. Remember to replace ${HOSTNAME} with the actual hostname.

cd /opt/caddy/certs
openssl req -x509 -nodes -days 365 -addext "subjectAltName = DNS:${HOSTNAME}" -newkey rsa:2048 -keyout ./key.pem -out ./cert.pem

Configure SeaTable Container to use custom certificates¶

The caddy docker proxy container from lucaslorentz supports dynamic configuration with labels.

It is not recommended to make changes to the provides seatable-server.yml. Create a custom yml file and reference it in your .env file instead. Add the following line to your custom-seatable-server.yml to tell caddy to use your custom certificates. The label caddy.tls will tell caddy to use your custom certificates.

# configuration of custom-seatable-server.yml
services:
  seatable-server:
    ...
    labels:
      caddy: ${SEATABLE_SERVER_HOSTNAME}
      caddy.tls: "/data/caddy/certs/cert.pem /data/caddy/certs/key.pem"
      ...

DNS resolution must work inside the container

If you're using a non-public url like "my-custom-setup.local", you have to make sure, that the docker container can resolve this DNS query. If you don't run your own DNS servers, you have to add extras_hosts to your .yml file.

Add certificates to your truststore¶

SeaTable Server and the Python Pipeline (Scheduler and Starter) execute the command update-ca-certificates at every start. This adds all certificates from /usr/local/share/ca-certificates/ to the system trust store at /etc/ssl/certs/ca-certificates.crt.

This is relevant in two scenarios:

Self-signed or custom SeaTable certificates: If SeaTable itself uses a self-signed or custom certificate, internal services need to trust it.
External services with custom CAs: If SeaTable connects to external services that use certificates from a non-standard CA (e.g. a corporate SAML/SSO identity provider, LDAP server, or S3 storage), you need to add the corresponding root CA certificate to the trust store.

To add a certificate, mount the .crt file into the container via your custom-seatable-server.yml. This works for seatable-server, python-scheduler, and python-starter.

services:
  seatable-server:
    ...
    volumes:
      ...
      - "/opt/caddy/certs/cert.pem:/usr/local/share/ca-certificates/cert.crt"

You can mount multiple certificates by adding additional volume mounts. Every .crt file in /usr/local/share/ca-certificates/ will be included in the trust store at startup.

REQUESTS_CA_BUNDLE is required

Make sure that REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt is set in your environment variables. This tells all Python libraries (requests, pysaml2, etc.) to use the system trust store instead of their own bundled certificates. This variable is included by default since version 5.0 in the seatable-server.yml.

Self-signed certificates generated by Caddy¶

Even if it is not recommended, it is possible to ask Caddy to use auto generated self-signed certificates. This can be achieved by adding these lines to your custom-seatable-server.yml.

# configuration of custom-seatable-server.yml
services:
  seatable-server:
    ...
    labels:
      caddy: ${SEATABLE_SERVER_HOSTNAME}
      caddy.tls: "internal"

Problems with local IP¶

The current setup does not allow that you add a local IP address as SEATABLE_SERVER_HOSTNAME in your .env file. There are two alternatives that we recommend to use:

use local address¶

Instead of the IP address you should use an address like seatable.local. This requires that you either use a self-signed certificate or a custom root certificate.

use nip.io¶

There is a free service https://nip.io which allows mapping any IP Address to a hostname using the following formats:

10.0.0.1.nip.io maps to 10.0.0.1
192-168-1-250.nip.io maps to 192.168.1.250
0a000803.nip.io maps to 10.0.8.3

So if you want to use the local address like 192.168.17.20, you should use 192.168.17.20.nip.io as SEATABLE_SERVER_HOSTNAME.

Limitations¶

Currently it is not possible to generate PDF-Files with the Page Design Plugin if you're running SeaTable with your self-signed certificate. The workaround is to use Print inside the Page Design Plugin and then use a local PDF-Printer to generate the PDF.