- linkend="auth-pg-hba-conf"> about how to set up the server to
-
require use of SSL> for some or all connections.
+
PostgreSQL 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 file.
OpenSSL supports a wide range of ciphers
- and authentication algorithms, whose strength varies significantly.
- You can restrict the list of ciphers that can be used to connect to
- your server by adjusting the parameter.
+ and authentication algorithms, of varying strength. While a list of
+ ciphers can be specified in the
OpenSSL
+ configuration file, you can specify ciphers specifically for use by
+ the database server by modifying in
+ postgresql.conf>.
-
PostgreSQL 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 file.
+ To start in
SSL> mode, the files server.crt>
+ and server.key> must exist in the server's data directory.
+ These files should contain the server certificate and private key,
+ respectively. If the private key is protected with a passphrase, the
+ server will prompt for the passphrase and will not start until it has
+ been entered.
+
+
+ To require the client to supply a trusted certificate, place
+ certificates of the certificate authorities (
CA)
+ you trust in the file root.crt in the data
+ directory. A certificate will then be requested from the client during
+ SSL connection startup. (See for a
+ description of how to set up client certificates.) The server will
+ verify that the client's certificate is signed by one of the trusted
+ certificate authorities. Certificate Revocation List (CRL) entries
+ are also checked if the file root.crl exists.
+
+
+ If the root.crt file is not present, client
+ certificates will not be requested or checked. In this mode, SSL
+ provides encrypted communication but not authentication.
- For details on how to create your server private key and certificate,
- refer to the
OpenSSL> documentation. A
- self-signed certificate can be used for testing, but a
- certificate signed by a certificate authority (
CA>)
- (either one of the global
-
CAs> or a local one) should be used in production so the
- client can verify the server's identity. To create a quick
- self-signed certificate, use the following
+ The files server.key>, server.crt>,
+ root.crt, and root.crl
+ are only examined during server start; so you must restart
+ the server for changes in them to take effect.
+
+
+
+
Creating a Self-Signed Certificate
+
+ To create a quick self-signed certificate for the server, use the
+ following
OpenSSL command:
openssl req -new -text -out server.req
- Fill out the information that
openssl> 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:
+
Fill out the information that
openssl> 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.key
rm privkey.pem
- Enter the old passphrase to unlock the existing key. Now do:
+ Enter the old passphrase to unlock the existing key. Now do:
openssl req -x509 -in server.req -text -key server.key -out server.crt
chmod og-rwx server.key
- to turn the certificate into a self-signed certificate and to copy the
- key and certificate to where the server will look for them.
-
+ to turn the certificate into a self-signed certificate and to copy
+ the key and certificate to where the server will look for them.
+ For more details on how to create your server private key and
+ certificate, refer to the
OpenSSL> documentation.
+
- If verification of client certificates is required, place the
- certificates of the
CA(s) you wish to check for in
- the file root.crt in the data directory. When
- present, a client certificate will be requested from the client
- during SSL connection startup, and it must have been signed by one of
- the certificates present in
root.crt. (See
- linkend="libpq-ssl"> for a description of how to set up client
- certificates.) Certificate Revocation List (CRL) entries are also
- checked if the file root.crl exists.
-
+ A self-signed certificate can be used for testing, but a certificate
+ signed by a certificate authority (
CA>) (either one of the
+ global
CAs> or a local one) should be used in production
+ so the client can verify the server's identity.
+
- When the root.crt file is not present, client
- certificates will not be requested or checked. In this mode, SSL
- provides communication security but not authentication.
-
+
- The files server.key>, server.crt>,
- root.crt, and root.crl
- are only examined during server start; so you must restart
- the server to make changes in them take effect.
-