> ## Documentation Index
> Fetch the complete documentation index at: https://support.lilt.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Trusting a Custom CA for S3 Storage

> Configure LILT's neural services to trust a private or corporate CA for S3-compatible object storage using AWS_CA_BUNDLE

## 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.

<Note>
  Requires LILT release 6.1 or later. Earlier releases ignore `AWS_CA_BUNDLE` on the neural S3 client.
</Note>

## 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`:

```yaml theme={null}
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:

```bash theme={null}
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.

## Related pages

* [Using S3 instead of MinIO](/system-administration/using-s3-instead-of-minio) — switching object storage backends
* [Set Custom Domain And Certificates](/kb/set-custom-domain-and-certificates) — TLS certificates for LILT's own ingress (a separate concern from S3 egress trust)