PostgreSQL supports SSL/TLS so client-server traffic stays unreadable to eavesdroppers.
Encryption in transit secures the network stream between client and server with SSL/TLS, blocking sniffing and man-in-the-middle attacks.
Set ssl = on
in postgresql.conf
, place a valid server.key
and server.crt
in $PGDATA
, then reload or restart the cluster.
openssl req -new -x509 -days 365 -nodes -text \
-out $PGDATA/server.crt -keyout $PGDATA/server.key
chmod 600 $PGDATA/server.key $PGDATA/server.crt
pg_hba.conf
Add a hostssl line, for example:hostssl ecommerce all 10.0.0.0/16 cert
Use connection parameters sslmode=require|verify-ca|verify-full
and supply CA certificates with sslrootcert
.
psql "host=db.internal port=5432 dbname=ecommerce user=app sslmode=verify-full sslrootcert=$HOME/.postgresql/root.crt"
Run SELECT ssl, ssl_cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid();
– ssl
should be t
.
Any DML/DDL (e.g., SELECT id, email FROM Customers;
) works the same; only the connection string changes.
ssl_ciphers
to modern suites only.clientcert=verify-full
in pg_hba.conf
.Combine certbot
or corporate PKI with PostgreSQL ALTER SYSTEM SET ssl_reload_config = on;
and signal pg_ctl reload
.
Query pg_stat_ssl
and integrate metrics (cipher, version) into Prometheus or New Relic.
.
Yes. Copy certificates, enable ssl = on
, and issue SELECT pg_reload_conf();
. Existing sessions persist; new ones negotiate TLS.
Handshake adds milliseconds; after that, symmetric encryption overhead is small (<2%). Network latency usually dominates.
No, but combining TLS with client certs gives mutual authentication and stronger security than password-only logins.