SSL Configuration for PostgreSQL: From Nginx Proxy Issues to Direct Database SSL
Introduction When working with PostgreSQL in production environments, SSL encryption is crucial for securing database connections. However, implementing SSL for PostgreSQL through an Nginx proxy can be tricky due to fundamental differences in how dat...
#postgresql-ssl-wrong-version-number#database-ssl-vs-http-ssl#ssl-handshake-failure#postgresql#ssltls-handshake#nginx#nomad#database-security#devops-articles#nginx-ssl-handshake-failed
Responses
Markdown supported · ⌘↵ to post
Useful walkthrough of why Postgres SSL and an HTTP reverse proxy do not compose the way people expect. Postgres speaks its own TLS profile on the wire; sticking nginx http{} in front of 5432 usually breaks the startup packet or leaves you terminating the wrong protocol. When I need encrypted DB access from apps outside the VPC I terminate TLS at Postgres itself (ssl=on, verify-full on the client) or use a dedicated TCP/TLS proxy that understands the Postgres protocol, not a generic HTTP proxy_pass.
Operationally I keep two checks after any change: openssl s_client -starttls postgres against the advertised host:port, and a libpq connection with sslmode=verify-full using the same CA the apps trust. If apps sit behind nginx for HTTP only, leave 5432 off the public listener entirely and reach the DB over a private network or SSH tunnel. Mixing "we put nginx in front of everything" with database ports is the fastest way to get intermittent handshake failures that look like auth bugs.