# envTls() function · @imqueue/core

Source: https://imqueue.org/api/core/latest/core.envtls/
Published: 2026-08-31
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/core 3.5.0 — generated reference, not hand-written

Builds a TLS configuration from the environment, for turning encryption on across a fleet without touching application code.

TLS is enabled by `IMQ_REDIS_TLS`, or implicitly by supplying any TLS material; `IMQ_REDIS_TLS=0` wins over both and disables it outright. The recognised variables are:

- `IMQ_REDIS_TLS` — enables TLS with Node's default verification against the system trust store - `IMQ_REDIS_TLS_CA_FILE` — PEM bundle of the trust anchors to verify the broker against, for a private CA - `IMQ_REDIS_TLS_CERT_FILE`, `IMQ_REDIS_TLS_KEY_FILE` — client certificate and its private key, for mutual TLS - `IMQ_REDIS_TLS_KEY_PASSPHRASE` — passphrase of an encrypted private key - `IMQ_REDIS_TLS_SERVERNAME` — expected certificate name, needed when the broker is reached at an address the certificate does not carry - `IMQ_REDIS_TLS_REJECT_UNAUTHORIZED` — set to `0` to accept an unverified certificate. This reduces the connection to encryption without authentication and leaves it open to interception; use it for a local experiment, never in a deployment.

Certificate files are read eagerly, and an unreadable one throws rather than yielding a configuration that would connect in the clear.

**Signature:**

```typescript
export declare function envTls(): TlsOptions | undefined;
```
**Returns:**

TlsOptions \| undefined

the configuration, or `undefined` when the environment asks for no TLS

## Exceptions

{Error} when TLS material is named but cannot be read