Note: It is possible to have authentication without encryption overhead by usingNULL-SHA orNULL-MD5 ciphers. However, a man-in-the-middle could read and pass communications between client and server. Also, encryption overhead is minimal compared to the overhead of authentication. For these reasons NULL ciphers are not recommended.

17.9.1. Using Client Certificates

To require the client to supply a trusted certificate, place certificates of the certificate authorities (CAs) you trust in the fileroot.crt in the data directory, set the parameterssl_ca_file inpostgresql.conf toroot.crt, and set theclientcert parameter to 1 on the appropriatehostssl line(s) inpg_hba.conf. A certificate will then be requested from the client during SSL connection startup. (SeeSection 31.18 for a description of how to set up certificates on the client.) The server will verify that the client's certificate is signed by one of the trusted certificate authorities. If intermediateCAs appear inroot.crt, the file must also contain certificate chains to their rootCAs. Certificate Revocation List (CRL) entries are also checked if the parameterssl_crl_file is set. (Seehttp://h71000.www7.hp.com/DOC/83final/BA554_90007/ch04s02.html for diagrams showing SSL certificate usage.)

Theclientcert option inpg_hba.conf is available for all authentication methods, but only for rows specified ashostssl. Whenclientcert is not specified or is set to 0, the server will still verify presented client certificates against its CA list, if one is configured, — but it will not insist that a client certificate be presented.

Note that the server'sroot.crt lists the top-level CAs that are considered trusted for signing client certificates. In principle it need not list the CA that signed the server's certificate, though in most cases that CA would also be trusted for client certificates.

If you are setting up client certificates, you may wish to use thecert authentication method, so that the certificates control user authentication as well as providing connection security. SeeSection 19.3.9 for details.

17.9.2. SSL Server File Usage

Table 17-2 summarizes the files that are relevant to the SSL setup on the server. (The shown file names are default or typical names. The locally configured names could be different.)

The filesserver.key,server.crt,root.crt, androot.crl (or their configured alternative names) are only examined during server start; so you must restart the server for changes in them to take effect.

17.9.3. Creating a Self-signed Certificate

To create a quick self-signed certificate for the server, use the followingOpenSSL command:

openssl req -new -text -out server.req

Fill out the information thatopenssl asks for. Make sure you enter the local host name as"Common Name"; the challenge password can be left blank. The program will generate a key that is passphrase protected; it will not accept a passphrase that is less than four characters long. To remove the passphrase (as you must if you want automatic start-up of the server), run the commands:

openssl rsa -in privkey.pem -out server.keyrm privkey.pem

Enter the old passphrase to unlock the existing key. Now do:

openssl req -x509 -in server.req -text -key server.key -out server.crt

to turn the certificate into a self-signed certificate and to copy the key and certificate to where the server will look for them. Finally do:

chmod og-rwx server.key

because the server will reject the file if its permissions are more liberal than this. For more details on how to create your server private key and certificate, refer to theOpenSSL documentation.

A self-signed certificate can be used for testing, but a certificate signed by a certificate authority (CA) (either one of the globalCAs or a local one) should be used in production so that clients can verify the server's identity. If all the clients are local to the organization, using a localCA is recommended.