# IMessageQueueAuthConnection.tls property · @imqueue/core

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

Encrypts this connection with TLS. `true` connects with Node's defaults, verifying the server against the system trust store; an object is handed to `tls.connect()` as given, so supply `ca` for a private certificate authority and `cert` with `key` for mutual TLS.

Applies to every channel the queue opens — reader, writer, watcher and subscription alike — so enabling it here encrypts the whole bus. The broker must be listening for TLS (`tls-port`); a server that is not will refuse the handshake rather than fall back to plaintext.

**Signature:**

```typescript
tls?: boolean | TlsOptions;
```

## Default Value

undefined

## Remarks

The certificate is verified against [IMessageQueueConnection.host](https://imqueue.org/api/core/latest/core.imessagequeueconnection.host/) unless `servername` says otherwise. A host that is a bare IP address therefore needs a certificate carrying that address as an IP SAN — reach the broker by the name on its certificate, or set `servername` to it.

The writer and watcher connections are shared per server within the process, and that sharing accounts for this option: queues reaching the same host and port under different TLS configurations get separate connections rather than silently inheriting whichever was opened first. Configurations that are equal by value still share.

When omitted, the environment is consulted instead — see `IMQ_REDIS_TLS` and its companions in [envTls()](https://imqueue.org/api/core/latest/core.envtls/) — which lets a deployment turn encryption on without a code change. Passing `false` declines that fallback and forces a plaintext connection.