Encryption in transit secures ParadeDB connections with TLS/SSL, protecting data exchanged between clients and the database.
Encryption in transit forces every ParadeDB connection to use TLS/SSL, turning plain-text packets into encrypted ones that eavesdroppers cannot read.
Generate a server key and certificate with OpenSSL, then a client key and certificate signed by the same CA.Store server.key
and server.crt
in $PGDATA
; distribute the client files securely.
Run ALTER SYSTEM SET ssl = on;
and define file paths with ssl_cert_file
, ssl_key_file
, and ssl_ca_file
. Reload or restart ParadeDB for changes to apply.
Add the same parameters directly in postgresql.conf
. Choose this when you prefer configuration-as-code over SQL commands.
Developers add sslmode=require
or verify-full
to their connection strings.Example: postgresql://app:secret@db.example.com/shop?sslmode=verify-full
.
Query SELECT ssl, client_addr FROM pg_stat_ssl WHERE pid = pg_backend_pid();
. A t
in the ssl
column confirms an encrypted session.
Use sslmode=verify-full
, rotate certificates regularly, and store keys with strict file permissions 0600
. Automate renewals with cert-manager or a CI job.
Incorrect file permissions cause ParadeDB to refuse startup. Fix by running chmod 0600 server.key
. Using sslmode=require
without hostname validation exposes you to MITM; switch to verify-full
.
.
Yes. Place the PEM files generated by Certbot in the locations referenced by ssl_cert_file and ssl_key_file, then reload.
No. SSL only secures the transport layer; it has no effect on on-disk data or indexes.
Add hostssl entries in pg_hba.conf
for those roles, rejecting non-SSL connections.