Skip to main content
In many enterprise environments, internal certificate authorities (CAs) or self-signed TLS certificates are used—for example for internal APIs, private container registries, or package repositories. The same is required when a firewall or proxy with TLS inspection breaks up outbound traffic and re-signs it with its own certificate, for example on the way to the model provider. For applications in the VARIOS AI container to trust these certificates, you can mount a custom CA certificate bundle from the host into the container. This configuration ensures that the container uses additional or custom CA certificates and can establish TLS connections to servers signed by your internal CAs.

Configuration

The PHP container does not start as root by default. update-ca-certificates requires root privileges. In your docker-compose.yml, adjust the PHP container as shown below and mount the certificate bundle as a volume. Remove any existing command on the PHP service. Startup is handled by the customized entrypoint.
The example path /etc/pki/tls/certs/ca-bundle.crt is typical for RHEL/CentOS systems. On Debian/Ubuntu, the system CA bundle is often at /etc/ssl/certs/ca-certificates.crt. Adjust the host path to match your distribution.

Apply

Save your docker-compose.yml and restart the containers:
If the containers are already running, restarting the PHP container is sufficient—for example, docker compose up -d php.

How It Works

On PHP container startup, the customized entrypoint runs these steps automatically—you do not need to execute anything manually:
  1. The CA bundle is mounted from the host to /usr/local/share/ca-certificates/.
  2. The container starts as root (user: "0:0") so that update-ca-certificates can add the certificates to the system-wide trust store.
  3. /scripts/entrypoint.sh switches to the application user (PUID/PGID) and starts VARIOS AI via /scripts/run.sh.

Result

After the container starts:
  • The host’s CA bundle is available inside the container.
  • The certificates are registered in the system-wide trust store.
  • Applications in the container can establish TLS connections to servers signed by these CAs.

Typical Use Cases

  • Using an internal corporate CA
  • Accessing internal APIs with self-signed certificates
  • Trust for private container registries or package repositories
  • Outbound traffic through a firewall or proxy with TLS inspection