Movatterモバイル変換

32.19.1. Client Verification of Server Certificates

32.19.2. Client Certificates

32.19.3. Protection Provided in Different Modes

32.19.4. SSL Client File Usage

32.19.5. SSL Library Initialization

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, the client must be able to verify the server's identity via a chain of trust. A chain of trust is established by placing a root (self-signed) certificate authority (CA) certificate on one computer and a leaf certificatesigned by the root certificate on another computer. It is also possible to use an“intermediate” certificate which is signed by the root certificate and signs leaf certificates.

To allow the client to verify the identity of the server, place a root certificate on the client and a leaf certificate signed by the root certificate on the server. To allow the server to verify the identity of the client, place a root certificate on the server and a leaf certificate signed by the root certificate on the client. One or more intermediate certificates (usually stored with the leaf certificate) can also be used to link the leaf certificate to the root certificate.

Once a chain of trust has been established, there are two ways for the client to validate the leaf certificate sent by the server. If the parametersslmode is set toverify-ca, libpq will verify that the server is trustworthy by checking the certificate chain up to the root certificate stored on the client. Ifsslmode is set toverify-full, libpq willalso verify that the server host name matches the name stored in the server certificate. The SSL connection will fail if the server certificate cannot be verified.verify-full is recommended in most security-sensitive environments.

Inverify-full mode, the host name is matched against the certificate's Subject Alternative Name attribute(s) (SAN), or against the Common Name attribute if no SAN of typedNSName is present. If the certificate's name attribute starts with an asterisk (*), the asterisk will be treated as a wildcard, which will match all charactersexcept 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) against SANs of typeiPAddress ordNSName. If noiPAddress SAN is present and no matchingdNSName SAN is present, the host IP address is matched against the Common Name attribute.

To allow server certificate verification, one or more root certificates must be placed in the file~/.postgresql/root.crt in the user's home directory. (On Microsoft Windows the file is named%APPDATA%\postgresql\root.crt.) Intermediate certificates should also be added to the file if they are needed to link the certificate chain sent by the server to the root certificates stored on the client.

Certificate Revocation List (CRL) entries are also checked if the file~/.postgresql/root.crl exists (%APPDATA%\postgresql\root.crl on Microsoft Windows).

The location of the root certificate file and the CRL can be changed by setting the connection parameterssslrootcert andsslcrl or the environment variablesPGSSLROOTCERT andPGSSLCRL.sslcrldir or the environment variablePGSSLCRLDIR can also be used to specify a directory containing CRL files.

If the server attempts to verify the identity of the client by requesting the client's leaf certificate,libpq will send the certificate(s) stored in file~/.postgresql/postgresql.crt in the user's home directory. The certificates must chain to the root certificate trusted by the server. A matching private key file~/.postgresql/postgresql.key must also be present. On Microsoft Windows these files are named%APPDATA%\postgresql\postgresql.crt and%APPDATA%\postgresql\postgresql.key. The location of the certificate and key files can be overridden by the connection parameterssslcert andsslkey, or by the environment variablesPGSSLCERT andPGSSLKEY.

On Unix systems, the permissions on the private key file must disallow any access to world or group; achieve this by a command such aschmod 0600 ~/.postgresql/postgresql.key. Alternatively, the file can be owned by root and have group read access (that is,0640 permissions). That setup is intended for installations where certificate and key files are managed by the operating system. The user oflibpq should then be made a member of the group that has access to those certificate and key files. (On Microsoft Windows, there is no file permissions check, since the%APPDATA%\postgresql directory is presumed secure.)

The first certificate inpostgresql.crt must be the client's certificate because it must match the client's private key.“Intermediate” certificates can be optionally appended to the file — doing so avoids requiring storage of intermediate certificates on the server (ssl_ca_file).

The certificate and key may be in PEM or ASN.1 DER format.

The key may be stored in cleartext or encrypted with a passphrase using any algorithm supported byOpenSSL, like AES-128. If the key is stored encrypted, then the passphrase may be provided in thesslpassword connection option. If an encrypted key is supplied and thesslpassword option is absent or blank, a password will be prompted for interactively byOpenSSL with aEnter PEM pass phrase: prompt if a TTY is available. Applications can override the client certificate prompt and the handling of thesslpassword parameter by supplying their own key password callback; seePQsetSSLKeyPassHook_OpenSSL.

For instructions on creating certificates, seeSection 18.9.5.

The different values for thesslmode parameter provide different levels of protection. SSL can provide protection against three types of attacks:

For a connection to be known SSL-secured, SSL usage must be configured onboth 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 thesslmode parameter toverify-full orverify-ca, and providing the system with a root certificate to verify against. This is analogous to using anhttpsURL 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.

AllSSL options carry overhead in the form of encryption and key-exchange, so there is a trade-off that has to be made between performance and security.Table 32.1 illustrates the risks the differentsslmode values protect against, and what statement they make about security and overhead.

The difference betweenverify-ca andverify-full depends on the policy of the rootCA. If a publicCA is used,verify-ca allows connections to a server thatsomebody else may have registered with theCA. In this case,verify-full should always be used. If a localCA is used, or even a self-signed certificate, usingverify-ca often provides enough protection.

The default value forsslmode isprefer. 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 backward compatibility, and is not recommended in secure deployments.

Table 32.2 summarizes the files that are relevant to the SSL setup on the client.

If your application initializeslibssl and/orlibcrypto libraries andlibpq is built withSSL support, you should callPQinitOpenSSL to telllibpq that thelibssl and/orlibcrypto libraries have been initialized by your application, so thatlibpq will not also initialize those libraries. However, this is unnecessary when usingOpenSSL version 1.1.0 or later, as duplicate initializations are no longer problematic.