PostgreSQL has native support for using SSL
connections to encrypt client/server communications for increased
security. See Section 17.8 for details about the server-side
libpq reads the system-wide
OpenSSL configuration file. By default, this
file is named openssl.cnf and is located in the
directory reported by openssl version -d. This default
can be overridden by setting environment variable
OPENSSL_CONF to the name of the desired configuration
By default, PostgreSQL will not perform any verification of
the server certificate. This means that it is possible to spoof the server
identity (for example by modifying a DNS record or by taking over the server
IP address) without the client knowing. In order to prevent spoofing,
SSL certificate verification must be used.
If the parameter sslmode is set to verify-ca,
libpq will verify that the server is trustworthy by checking the
certificate chain up to a trusted certificate authority
(CA). If sslmode is set to verify-full,
libpq will also verify that the server host name matches its
certificate. The SSL connection will fail if the server certificate cannot
be verified. verify-full is recommended in most
In verify-full mode, the cn (Common Name) attribute
of the certificate is matched against the host name. If the cn
attribute starts with an asterisk (*), it will be treated as
a wildcard, and will match all characters except a dot
(.). This means the certificate will not match subdomains.
If the connection is made using an IP address instead of a host name, the
IP address will be matched (without doing any DNS lookups).
To allow server certificate verification, the certificate(s) of one or more
trusted CAs must be
placed in the file ~/.postgresql/root.crt in the user's home
directory. (On Microsoft Windows the file is named
Certificate Revocation List (CRL) entries are also checked
if the file ~/.postgresql/root.crl exists
(%APPDATA%\postgresql\root.crl on Microsoft
The location of the root certificate file and the CRL can be changed by
the connection parameters sslrootcert and sslcrl
or the environment variables PGSSLROOTCERT and PGSSLCRL.
Note: For backwards compatibility with earlier versions of PostgreSQL, if a
root CA file exists, the behavior of
sslmode=require will be the same
as that of verify-ca, meaning the server certificate
is validated against the CA. Relying on this behavior is discouraged,
and applications that need certificate validation should always use
verify-ca or verify-full.
If the server requests a trusted client certificate,
libpq will send the certificate stored in
file ~/.postgresql/postgresql.crt in the user's home
directory. The certificate must be signed by one of the certificate
authorities (CA) trusted by the server. A matching
private key file ~/.postgresql/postgresql.key must also
be present. The private
key file must not allow any access to world or group; achieve this by the
command chmod 0600 ~/.postgresql/postgresql.key.
On Microsoft Windows these files are named
%APPDATA%\postgresql\postgresql.key, and there
is no special permissions check since the directory is presumed secure.
The location of the certificate and key files can be overridden by the
connection parameters sslcert and sslkey or the
environment variables PGSSLCERT and PGSSLKEY.
In some cases, the client certificate might be signed by an
"intermediate" certificate authority, rather than one that is
directly trusted by the server. To use such a certificate, append the
certificate of the signing authority to the postgresql.crt
file, then its parent authority's certificate, and so on up to a
"root" authority that is trusted by the server. The root
certificate should be included in every case where
postgresql.crt contains more than one certificate.
Note that root.crt lists the top-level CAs that are
considered trusted for signing server certificates. In principle it need
not list the CA that signed the client's certificate, though in most cases
that CA would also be trusted for server certificates.
The different values for the sslmode parameter provide different
levels of protection. SSL can provide
protection against three types of attacks:
Table 31-2. SSL attacks
|Eavesdropping||If a third party can examine the network traffic between the
client and the server, it can read both connection information (including
the user name and password) and the data that is passed. SSL
uses encryption to prevent this.
|Man in the middle (MITM)||If a third party can modify the data while passing between the
client and server, it can pretend to be the server and therefore see and
modify data even if it is encrypted. The third party can then
forward the connection information and data to the original server,
making it impossible to detect this attack. Common vectors to do this
include DNS poisoning and address hijacking, whereby the client is directed
to a different server than intended. There are also several other
attack methods that can accomplish this. SSL uses certificate
verification to prevent this, by authenticating the server to the client.
|Impersonation||If a third party can pretend to be an authorized client, it can
simply access data it should not have access to. Typically this can
happen through insecure password management. SSL uses
client certificates to prevent this, by making sure that only holders
of valid certificates can access the server.
For a connection to be known secure, SSL usage must be configured
on both the client and the server before the connection
is made. If it is only configured on the server, the client may end up
sending sensitive information (e.g. passwords) before
it knows that the server requires high security. In libpq, secure
connections can be ensured
by setting the sslmode parameter to verify-full or
verify-ca, and providing the system with a root certificate to
verify against. This is analogous to using an https
URL for encrypted web browsing.
Once the server has been authenticated, the client can pass sensitive data.
This means that up until this point, the client does not need to know if
certificates will be used for authentication, making it safe to specify that
only in the server configuration.
All SSL options carry overhead in the form of encryption and
key-exchange, so there is a tradeoff that has to be made between performance
and security. The following table illustrates the risks the different
sslmode values protect against, and what statement they make
about security and overhead:
Table 31-3. SSL mode descriptions
|sslmode||Eavesdropping protection||MITM protection||Statement|
|disable||No||No||I don't care about security, and I don't want to pay the overhead
|allow||Maybe||No||I don't care about security, but I will pay the overhead of
encryption if the server insists on it.
|prefer||Maybe||No||I don't care about encryption, but I wish to pay the overhead of
encryption if the server supports it.
|require||Yes||No||I want my data to be encrypted, and I accept the overhead. I trust
that the network will make sure I always connect to the server I want.
|verify-ca||Yes||Depends on CA-policy||I want my data encrypted, and I accept the overhead. I want to be
sure that I connect to a server that I trust.
|verify-full||Yes||Yes||I want my data encrypted, and I accept the overhead. I want to be
sure that I connect to a server I trust, and that it's the one I
The difference between verify-ca and verify-full
depends on the policy of the root CA. If a public
CA is used, verify-ca allows connections to a server
that somebody else may have registered with the CA.
In this case, verify-full should always be used. If
a local CA is used, or even a self-signed certificate, using
verify-ca often provides enough protection.
The default value for sslmode is prefer. As is shown
in the table, this makes no sense from a security point of view, and it only
promises performance overhead if possible. It is only provided as the default
for backwards compatibility, and is not recommended in secure deployments.
Table 31-4. Libpq/Client SSL File Usage
|~/.postgresql/postgresql.crt||client certificate||requested by server|
|~/.postgresql/postgresql.key||client private key||proves client certificate sent by owner; does not indicate
certificate owner is trustworthy|
|~/.postgresql/root.crt||trusted certificate authorities||checks that server certificate is signed by a trusted certificate
|~/.postgresql/root.crl||certificates revoked by certificate authorities||server certificate must not be on this list|
If your application initializes libssl and/or
libcrypto libraries and libpq
is built with SSL support, you should call
PQinitOpenSSL to tell libpq
that the libssl and/or libcrypto libraries
have been initialized by your application, so that
libpq will not also initialize those libraries.
for details on the SSL API.
Allows applications to select which security libraries to initialize.
void PQinitOpenSSL(int do_ssl, int do_crypto);
When do_ssl is non-zero, libpq
will initialize the OpenSSL library before first
opening a database connection. When do_crypto is
non-zero, the libcrypto library will be initialized. By
PQinitOpenSSL is not called), both libraries
are initialized. When SSL support is not compiled in, this function is
present but does nothing.
If your application uses and initializes either OpenSSL
or its underlying libcrypto library, you must
call this function with zeroes for the appropriate parameter(s)
before first opening a database connection. Also be sure that you
have done that initialization before opening a database connection.
Allows applications to select which security libraries to initialize.
void PQinitSSL(int do_ssl);
This function is equivalent to
It is sufficient for applications that initialize both or neither
of OpenSSL and libcrypto.
PQinitSSL has been present since
PostgreSQL 8.0, while
was added in PostgreSQL 8.4, so
might be preferable for applications that need to work with older
versions of libpq.