18.9. Secure TCP/IP connection with SSL
PostgreSQL has a native support for encrypting client/server communication using SSL connections, which can increase security. This feature requires OpenSSL to be installed on both the client and server and to enable this support when compiling PostgreSQL (see Chapter 16).
18.9.1. Basic Setup
When SSL support is compiled in PostgreSQL, the PostgreSQL server can be started with SSL support by setting ssl in postgresql.conf to on. The server monitors normal connections and SSL connections on the same TCP port, and will negotiate with any connecting clients whether to use SSL. By default, this is an option on the client side,
For information on how to set up the server to require SSL for some or all connections, see Section 20.1. To start the server in SSL mode, the file containing the server certificate and private key must exist. By default, these files should be named server.crt and server.key respectively and placed in the server's data directory, but you can specify other names and locations through the configuration parameters ssl_cert_file and ssl_key_file.
On Unix systems, the permissions on server.key must not allow any access by everyone or group, which chmod 0600 server.keycan be done through commands . Alternatively, the file can be owned by root and has group read access (that is, 0640 permissions). This setting is suitable for the installation of certificates and key files managed by the operating system. The user used to run the PostgreSQL server should be a member of the group that can access those certificate and key files.
If the data directory allows group read access, the certificate file may need to be located outside the data directory to meet the security requirements outlined above. Generally, the purpose of enabling group access is to allow non-privileged users to back up the database. In this case, the backup software will not be able to read the certificate file and errors may occur.
If the private key is protected by a password, the server will prompt for this password and will not start until it is entered. Using a password also disables the ability to change the server's SSL configuration without restarting the server. In addition, the password-protected private key cannot be used at all on Windows.
The first certificate in server.crt must be the server's certificate, because it must match the server's private key. The "intermediate" certification authority can also be appended to the file. Assuming that the root certificate and the intermediate certificate are created with the v3_ca extension, this avoids the need to store the intermediate certificate on the client. This makes it easier for intermediate certificates to expire.
No need to add the root certificate to server.crt. Instead, the client must have the root certificate of the server certificate chain.
18.9.2. OpenSSL configuration
PostgreSQL reads the system-wide OpenSSL configuration file. By default, the file is named openssl.cnf and is located in the directory reported by openssl version -d. This default value can be overridden by setting the environment variable OPENSSL_CONF to the name of the required configuration file.
OpenSSL supports various passwords and authentication algorithms with different strengths. Although many passwords can be specified in the OpenSSL configuration file, you can modify the postgresql.confconfiguration file to specify a configuration specifically for the use of passwords for the database server ssl_ciphers.
Use NULL-SHA or NULL-MD5 to get authentication but no encryption overhead. However, the middleman can read and pass the communication between the client and the server. In addition, the cost of encryption is minimal compared to the cost of identity authentication. For these reasons, we recommend not to use NULL passwords.
18.9.3. Using client certificates
Ask the client to provide a trusted certificate, and place the certificate of your trusted root certification authority (CA) in the data directory file. And modify the parameter ssl_ca_file in postgresql.conf to the new file name, and add the authentication option clientcert=1 to the appropriate hostssl line in the pg_hba.conf file. Then the certificate will be requested from the client when the SSL connection is started (for a description of how to set the certificate on the client, please see Section 34.18). The server will verify that the client's certificate is signed by one of the trusted certification authorities.
If you want to avoid displaying the intermediate certificates linked to the existing root certificates in the ssl_ca_file file (assuming that the root certificates and intermediate certificates are created with the v3_ca extension), these certificates can also be displayed in the ssl_ca_file file. If the parameter ssl_crl_file is set, the certificate revocation list (CRL) item will also be checked (see the icon showing the usage of the SSL certificate http://h41379.www4.hpe.com/doc/83final/ba554_90007/ch04s02.html).
The clientcert authentication option applies to all authentication methods, but only to the line specified by hostssl in pg_hba.conf. When clientcert is not specified or set to 0, if a CA file is configured, the server will still verify any submitted client certificate against it — but it will not insist on presenting a client certificate.
If you are setting up a client certificate, you may want to use the cert authentication method, so that the certificate controls user authentication and provides connection security. For details, see Section 20.12 (when using the cert authentication method, it is not necessary to explicitly specify clientcert=1).
18.9.4. SSL server file usage
Table 18.2 summarizes the files related to the SSL configuration on the server (the file name shown is the default name. The name of the local configuration may be different).
Table 18.2. SSL server file usage The
server reads these files when the server starts and when the server configuration is reloaded. On Windows systems, as long as a new backend process is generated for a new client connection, they will also be read again.
If errors in these files are detected when the server starts, the server will refuse to start. However, if errors are detected during configuration reloading, these files will be ignored and the old SSL configuration will continue to be used. On Windows systems, if errors in these files are detected when the backend starts, the backend will not be able to establish an SSL connection. In all these cases, the error condition will be reported in the server log.
18.9.5. Create Certificate
To create a simple self-signed certificate with a validity period of 365 days for the server, you can use the following OpenSSL command and dbhost.yourdomain.comreplace it with the server's hostname:
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
Then execute:
chmod og-rwx server.key
If the file's permissions are more free than this, the server will reject the file. For more details on how to create your server private key and certificate, please refer to the OpenSSL documentation.
Although you can use a self-signed certificate for testing, you should use a certificate signed by a certification authority (CA) (usually an enterprise-wide root CA) in production.
To create a server certificate whose identity can be verified by the client, first create a certificate signing request (CSR) and a public/private key file:
openssl req -new -nodes -text -out root.csr \
-keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
Then, use the key to sign the request to create a root certificate authority (using the default OpenSSL configuration file location on Linux):
openssl x509 -req -in root.csr -text -days 3650 \
-extfile /etc/ssl/openssl.cnf -extensions v3_ca \
-signkey root.key -out root.crt
Finally, create a server certificate signed by the new root certification authority:
openssl req -new -nodes -text -out server.csr \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
-CA root.crt -CAkey root.key -CAcreateserial \
-out server.crt
server.crt and server.key should be stored on the server, and root.crt should be stored on the client so that the client can verify that the server's leaf certificate has been signed by its trusted root certificate. The root.key should be stored offline for use in creating future certificates.
You can also create a chain of trust that includes intermediate certificates:
# root
openssl req -new -nodes -text -out root.csr \
-keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
openssl x509 -req -in root.csr -text -days 3650 \
-extfile /etc/ssl/openssl.cnf -extensions v3_ca \
-signkey root.key -out root.crt
# intermediate
openssl req -new -nodes -text -out intermediate.csr \
-keyout intermediate.key -subj "/CN=intermediate.yourdomain.com"
chmod og-rwx intermediate.key
openssl x509 -req -in intermediate.csr -text -days 1825 \
-extfile /etc/ssl/openssl.cnf -extensions v3_ca \
-CA root.crt -CAkey root.key -CAcreateserial \
-out intermediate.crt
# leaf
openssl req -new -nodes -text -out server.csr \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
-CA intermediate.crt -CAkey intermediate.key -CAcreateserial \
-out server.crt
server.crtAnd intermediate.crtshould be connected into a certificate file package and stored on the server. server.key should also be stored on the server. root.crt should be stored on the client so that the client can verify that the server's leaf certificate has been signed by the certificate chain linked to its trusted root certificate. root.key and intermediate.keyshould be stored offline for use in creating future certificates.