SSL/TLS Configuration

Q: How do I test TLS quickly?

psql "sslmode=require" then \conninfo. OpenSSL: openssl s_client -starttls postgres -connect host:5432.

Q: Can I use TLS 1.3 only?

PostgreSQL supports TLS 1.2+. Set ssl_min_protocol_version and verify client library compatibility.

Q: What about replication TLS?

Use hostssl for replication entries and primary_conninfo with sslmode=verify-full on standbys.

Q: Self-signed certs in dev?

sslmode=require is acceptable locally. Production should use proper CA or managed provider bundle.

Q: Where to store sslrootcert in K8s?

Mount CA as Secret volume; reference path in DATABASE_URL. Rotate via rolling deploy.

Q: Does logical replication use TLS?

Yes when connection string sets sslmode. Treat replication links like application traffic.

TLS encrypts PostgreSQL traffic between clients and servers. In cloud and hybrid networks, treat unencrypted connections as a policy violation. PostgreSQL 18.4 supports modern TLS with hostssl in pg_hba.conf and sslmode=verify-full on clients for hostname-checked mutual trust.

Recipe

# postgresql.conf
ssl = on
ssl_cert_file = '/etc/postgresql/server.crt'
ssl_key_file  = '/etc/postgresql/server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf - reject non-TLS from app subnets
hostssl  all  all  10.20.0.0/16  scram-sha-256
hostnossl all all  0.0.0.0/0     reject

# Client connection string
psql "host=db.internal port=5432 dbname=orders user=app_api sslmode=verify-full sslrootcert=/etc/ssl/certs/ca.pem"

When to reach for this:

Any client crossing an untrusted network (VPC peering, VPN, public endpoint)
Compliance requirements for encryption in transit
Managed Postgres where you still must set sslmode on apps and rotate CA bundles

Working Example

Self-hosted primary with Let's Encrypt server cert and app clients verifying hostname.

# Generate or obtain server cert (simplified self-signed for lab)
openssl req -new -x509 -days 365 -nodes -text \
  -out server.crt -keyout server.key -subj "/CN=db.prod.internal"
chmod 600 server.key
chown postgres:postgres server.crt server.key

# postgresql.conf
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf
hostssl  orders  app_api  10.20.0.0/16  scram-sha-256

# App DSN (Node pg example)
export DATABASE_URL="postgresql://app_api@db.prod.internal:5432/orders?sslmode=verify-full&sslrootcert=/etc/app/ca.crt"

What this demonstrates:

Server presents certificate; clients require TLS via hostssl
verify-full checks CA and hostname match
Non-TLS connections from app CIDR are rejected explicitly

Deep Dive

sslmode Client Matrix

sslmode	Encrypts	Verifies CA	Verifies hostname
`disable`	No	No	No
`require`	Yes	No	No
`verify-ca`	Yes	Yes	No
`verify-full`	Yes	Yes	Yes

Use verify-full for production application connections unless a managed proxy documents a different trust model.

Certificate Rotation

# Zero-downtime reload after replacing server.crt/server.key
pg_ctl reload -D /var/lib/postgresql/data
# Or SQL:
SELECT pg_reload_conf();

Rotate server certs before expiry (30-day warning). Update client sslrootcert when CA changes.

Managed Cloud Notes

Provider	Server TLS	Client action
RDS / Aurora	Enforced on public endpoints	Download RDS CA bundle, `sslmode=verify-full`
Cloud SQL	Server-managed	Use connector or SSL params from console
Neon / Supabase	TLS by default	Use provided connection string with `sslmode=require` minimum

Gotchas

sslmode=require without CA verify - encrypted but vulnerable to MITM with rogue cert. Fix: verify-full + pinned CA.
host + hostssl both allowing same CIDR - clients may fall back to plaintext if misconfigured. Fix: hostnossl ... reject for sensitive ranges.
Expired server cert after auto-renewal on disk - Postgres does not hot-reload certs on all platforms. Fix: pg_reload_conf() in cert renewal hook.
Wrong CN/SAN on cert - verify-full fails with hostname mismatch. Fix: cert SAN includes db.prod.internal exactly as clients connect.
TLS termination at PgBouncer only - hop between pooler and Postgres may be plaintext inside VPC. Fix: TLS to Postgres too when threat model includes east-west sniffing.
Java trust store missing RDS CA - apps fail with PKIX errors. Fix: import provider CA bundle in JVM truststore or container image.

Alternatives

Alternative	Use When	Don't Use When
Private Service Connect / VPC-only	No public endpoint exists	Clients outside VPC need access
SSH tunnel / VPN	Legacy apps cannot set sslmode	You can fix client DSN properly
mTLS client certs (`cert` auth)	Service-to-service with few clients	Large fleet of dynamic app instances
IP allowlist only	Extra layer with TLS	As sole control (IPs spoofable internally)

FAQs

Is TLS enough without SCRAM?

No. TLS protects on the wire; SCRAM protects password verifier storage and challenge-response on login.

Does PgBouncer need TLS?

Yes for client-to-pooler when clients are outside the DB VLAN. Pooler-to-Postgres TLS depends on your east-west threat model.

How do I test TLS quickly?

psql "sslmode=require" then \conninfo. OpenSSL: openssl s_client -starttls postgres -connect host:5432.

Can I use TLS 1.3 only?

PostgreSQL supports TLS 1.2+. Set ssl_min_protocol_version and verify client library compatibility.

What about replication TLS?

Use hostssl for replication entries and primary_conninfo with sslmode=verify-full on standbys.

Performance impact?

Small on modern CPUs with session reuse. Bottleneck is still queries and disk, not TLS handshake at steady state.

Self-signed certs in dev?

sslmode=require is acceptable locally. Production should use proper CA or managed provider bundle.

Where to store sslrootcert in K8s?

Mount CA as Secret volume; reference path in DATABASE_URL. Rotate via rolling deploy.

Does logical replication use TLS?

Yes when connection string sets sslmode. Treat replication links like application traffic.

How does this interact with SCRAM?

Orthogonal layers: TLS for transport, SCRAM for password authentication after channel is encrypted.

Security Basics - threat model
SCRAM Authentication - password auth
Connection Proxies - PgBouncer TLS hops
Managed Postgres Basics - cloud TLS defaults
Security Best Practices - hardening checklist

Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.

Recipe

# postgresql.conf
ssl = on
ssl_cert_file = '/etc/postgresql/server.crt'
ssl_key_file  = '/etc/postgresql/server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf - reject non-TLS from app subnets
hostssl  all  all  10.20.0.0/16  scram-sha-256
hostnossl all all  0.0.0.0/0     reject

# Client connection string
psql "host=db.internal port=5432 dbname=orders user=app_api sslmode=verify-full sslrootcert=/etc/ssl/certs/ca.pem"

When to reach for this:

Any client crossing an untrusted network (VPC peering, VPN, public endpoint)
Compliance requirements for encryption in transit
Managed Postgres where you still must set sslmode on apps and rotate CA bundles

Working Example

Self-hosted primary with Let's Encrypt server cert and app clients verifying hostname.

# Generate or obtain server cert (simplified self-signed for lab)
openssl req -new -x509 -days 365 -nodes -text \
  -out server.crt -keyout server.key -subj "/CN=db.prod.internal"
chmod 600 server.key
chown postgres:postgres server.crt server.key

# postgresql.conf
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_min_protocol_version = 'TLSv1.2'

# pg_hba.conf
hostssl  orders  app_api  10.20.0.0/16  scram-sha-256

# App DSN (Node pg example)
export DATABASE_URL="postgresql://app_api@db.prod.internal:5432/orders?sslmode=verify-full&sslrootcert=/etc/app/ca.crt"

What this demonstrates:

Server presents certificate; clients require TLS via hostssl
verify-full checks CA and hostname match
Non-TLS connections from app CIDR are rejected explicitly

Deep Dive

sslmode Client Matrix

sslmode	Encrypts	Verifies CA	Verifies hostname
`disable`	No	No	No
`require`	Yes	No	No
`verify-ca`	Yes	Yes	No
`verify-full`	Yes	Yes	Yes

Use verify-full for production application connections unless a managed proxy documents a different trust model.

Certificate Rotation

# Zero-downtime reload after replacing server.crt/server.key
pg_ctl reload -D /var/lib/postgresql/data
# Or SQL:
SELECT pg_reload_conf();

Rotate server certs before expiry (30-day warning). Update client sslrootcert when CA changes.

Managed Cloud Notes

Provider	Server TLS	Client action
RDS / Aurora	Enforced on public endpoints	Download RDS CA bundle, `sslmode=verify-full`
Cloud SQL	Server-managed	Use connector or SSL params from console
Neon / Supabase	TLS by default	Use provided connection string with `sslmode=require` minimum

Gotchas

sslmode=require without CA verify - encrypted but vulnerable to MITM with rogue cert. Fix: verify-full + pinned CA.
host + hostssl both allowing same CIDR - clients may fall back to plaintext if misconfigured. Fix: hostnossl ... reject for sensitive ranges.
Expired server cert after auto-renewal on disk - Postgres does not hot-reload certs on all platforms. Fix: pg_reload_conf() in cert renewal hook.
Wrong CN/SAN on cert - verify-full fails with hostname mismatch. Fix: cert SAN includes db.prod.internal exactly as clients connect.
TLS termination at PgBouncer only - hop between pooler and Postgres may be plaintext inside VPC. Fix: TLS to Postgres too when threat model includes east-west sniffing.
Java trust store missing RDS CA - apps fail with PKIX errors. Fix: import provider CA bundle in JVM truststore or container image.

Alternatives

Alternative	Use When	Don't Use When
Private Service Connect / VPC-only	No public endpoint exists	Clients outside VPC need access
SSH tunnel / VPN	Legacy apps cannot set sslmode	You can fix client DSN properly
mTLS client certs (`cert` auth)	Service-to-service with few clients	Large fleet of dynamic app instances
IP allowlist only	Extra layer with TLS	As sole control (IPs spoofable internally)

FAQs

Is TLS enough without SCRAM?

No. TLS protects on the wire; SCRAM protects password verifier storage and challenge-response on login.

Does PgBouncer need TLS?

Yes for client-to-pooler when clients are outside the DB VLAN. Pooler-to-Postgres TLS depends on your east-west threat model.

How do I test TLS quickly?

psql "sslmode=require" then \conninfo. OpenSSL: openssl s_client -starttls postgres -connect host:5432.

Can I use TLS 1.3 only?

PostgreSQL supports TLS 1.2+. Set ssl_min_protocol_version and verify client library compatibility.

What about replication TLS?

Use hostssl for replication entries and primary_conninfo with sslmode=verify-full on standbys.

Performance impact?

Small on modern CPUs with session reuse. Bottleneck is still queries and disk, not TLS handshake at steady state.

Self-signed certs in dev?

sslmode=require is acceptable locally. Production should use proper CA or managed provider bundle.

Where to store sslrootcert in K8s?

Mount CA as Secret volume; reference path in DATABASE_URL. Rotate via rolling deploy.

Does logical replication use TLS?

Yes when connection string sets sslmode. Treat replication links like application traffic.

How does this interact with SCRAM?

Orthogonal layers: TLS for transport, SCRAM for password authentication after channel is encrypted.

Security Basics - threat model
SCRAM Authentication - password auth
Connection Proxies - PgBouncer TLS hops
Managed Postgres Basics - cloud TLS defaults
Security Best Practices - hardening checklist

Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.

SSL/TLS Configuration

Search Documentation

SSL/TLS Configuration