Postgresql

When implementing secure PostgreSQL connections, certificate creation forms the foundation of your PKI infrastructure. Whether you’re setting up a development environment or deploying enterprise-grade systems, understanding proper certificate creation practices is crucial. This guide explores certificate creation from the simple OpenSSL approach to enterprise-grade practices employed by major financial institutions like Credit Suisse/UBS and media companies like BBC. Related Reading: For implementing DN-based certificate authentication in PostgreSQL, see our DN Authentication guide. ...

Today, I’m diving into Distinguished Name (DN) authentication—a powerful feature that enables certificate-based authentication when the Common Name (CN) in your client certificate doesn’t match your PostgreSQL username. This approach is essential in enterprise environments where certificate naming conventions don’t align with database user naming requirements. Version Compatibility: The clientname=DN feature was introduced in PostgreSQL 14. If you’re using PostgreSQL 13 or earlier versions, this DN authentication method will not work and you’ll need to use traditional CN-based certificate authentication instead. ...

Mutual TLS (mTLS) for PostgreSQL provides strong, passwordless authentication and encryption. The most common cause of failed secure connections in real deployments is incorrect Subject Alternative Name (SAN) handling and trust configuration on the client side. This post explains how to set up SANs correctly, how hostname verification really works, and how to align PostgreSQL with enterprise PKI practices—using this repository’s cluster as a concrete example. Why SAN Matters More Than CN Modern TLS stacks validate the server’s identity against the SAN extension on the server certificate—not the Common Name (CN). When a PostgreSQL client connects to a host name (or IP), it will check: ...