Connection DSNs and SSL (TLS)

Because nodes connect using libpq , the DSN of a node is a

libpq connection string. As such, the connection string can

contain any permitted libpq connection parameter, including those for SSL. The DSN must work as the connection string from the client connecting to the node in which it’s specified. An example of such a set of parameters using a client certificate is:

sslmode=verify-full sslcert=bdr_client.crt sslkey=bdr_client.key
sslrootcert=root.crt

With this setup, the files bdr_client.crt , bdr_client.key , and root.crt must be present in the data directory on each node, with the appropriate permissions. For verify-full mode, the server’s SSL certificate is checked to ensure that it’s directly or indirectly signed with the root.crt certificate authority and that the host name or address used in the connection matches the contents of the certificate. In the case of a name, this can match a subject’s alternative name or, if there are no such names in the certificate, the subject’s common name (CN) field. Postgres doesn’t currently support subject alternative names for IP addresses, so if the connection is made by address rather than name, it must match the CN field.

The CN of the client certificate must be the name of the user making the PGD connection, which is usually the user postgres. Each node requires matching lines permitting the connection in the pg_hba.conf file. For example:

hostssl all         postgres 10.1.2.3/24 cert
hostssl replication postgres 10.1.2.3/24 cert

Another setup might be to use SCRAM-SHA-256 passwords instead of client certificates and not verify the server identity as long as the certificate is properly signed. Here the DSN parameters might be:

sslmode=verify-ca sslrootcert=root.crt

The corresponding pg_hba.conf lines are:

hostssl all         postgres 10.1.2.3/24 scram-sha-256
hostssl replication postgres 10.1.2.3/24 scram-sha-256

In such a scenario, the postgres user needs a .pgpass file containing the correct password.