Trusting a Custom CA for S3 Storage

Overview

Some self-managed environments reach their S3-compatible object storage through TLS that is not signed by a public certificate authority — for example:

An S3-compatible endpoint (MinIO, ECS, StorageGRID, etc.) serving a certificate issued by a private or corporate CA
A TLS-inspecting egress proxy that re-signs traffic to AWS S3 with a corporate CA

In these environments, LILT’s neural services must be told to trust that CA, or S3 requests fail TLS verification. This page covers the supported way to do that: the standard AWS SDK AWS_CA_BUNDLE environment variable.

Requires LILT release 6.1 or later. Earlier releases ignore AWS_CA_BUNDLE on the neural S3 client.

Why not `SSL_ENABLED`?

The SSL_ENABLED switch exists, but it is a shared switch: enabling it also forces application-level TLS on the Redis and RabbitMQ connections. On deployments where the service mesh already secures pod-to-pod traffic (Istio ambient mode), that breaks Redis and RabbitMQ connectivity. AWS_CA_BUNDLE scopes the custom CA to S3 only and leaves everything else untouched.

Configuration

Neural services deploy via the shared lilt-application chart, so the wiring is a plain environment variable plus a volume mount on each neural service block in lilt/values.yaml:

translatev4:
  env:
    AWS_CA_BUNDLE: /certs/client/ca-bundle.crt
  volumes:
    - name: s3-ca
      secret:
        secretName: neural-s3-ca          # Secret with key ca-bundle.crt
  volumeMounts:
    - name: s3-ca
      mountPath: /certs/client
      readOnly: true

Create the Secret from your CA bundle file first:

kubectl create secret generic neural-s3-ca \
  --namespace lilt \
  --from-file=ca-bundle.crt=/path/to/ca-bundle.crt

Repeat the env / volumes / volumeMounts block for every neural service that talks to S3 (translatev4, updatev4, update-managerv4, langid, routing, batchv4, batch-worker-gpuv4, batch-worker-cpu-3pmt, automqm, alignment, tag-projection, nncache, and the vLLM/Whisper inference services), then run the installer as usual.

Requirements and behavior

The file must be a complete CA bundle. A path in AWS_CA_BUNDLE replaces the AWS SDK’s default trust store rather than extending it. Concatenate the public root CAs your endpoint chain needs (for AWS S3, the public AWS roots) together with your private CA into one PEM file.
Use a CA certificate, not a client certificate. Pointing AWS_CA_BUNDLE at a client cert such as tls.crt produces a trust store that can verify nothing.
Plain-HTTP endpoints ignore it. If your S3 endpoint URL is http:// (the default in-cluster MinIO wiring), there is no TLS handshake and AWS_CA_BUNDLE has no effect. It only matters for https:// endpoints.
Leave it unset on EKS. EKS deployments reach AWS S3 directly, and those certificates verify against the default trust store. Setting AWS_CA_BUNDLE there would only narrow trust.
SSL_ENABLED takes precedence. If SSL_ENABLED=true with VERIFY_IDENTITY is configured, the neural services use /certs/client/ca.crt from that configuration and AWS_CA_BUNDLE is not consulted.

Using S3 instead of MinIO — switching object storage backends
Set Custom Domain And Certificates — TLS certificates for LILT’s own ingress (a separate concern from S3 egress trust)

​Overview

​Why not SSL_ENABLED?

​Configuration

​Requirements and behavior

​Related pages

Overview

Why not `SSL_ENABLED`?

Configuration

Requirements and behavior

Related pages