F.21. keycmd #

F.21.1. Example

keycmd is one particular implementation of the command to retrieve the encryption key for the PostgreSQL server. It consists of two scripts:

  1. key_listener - this is to be called via the encryption_key_command configuration variable, as described in Chapter 31. It binds to the specified port and waits for the key. Once the key has arrived, it's printed to the standard output.

    key_listener [--host host] [--port port] [--certs directory] [--cert-file file] [--key-file file] [--log file]

    Following is description of the options:

    --host

    Host or IP on which the listener waits for the encryption key.

    --port

    Port on which the listener waits for the encryption key.

    --certs

    Directory in which the listener expects the SSL certificates to initialize the secured connection for the key transfer. If not specified, it looks for the certificates in the current directory.

    --cert-file

    Certificate file name, defaults to server.crt

    --key-file

    Key file name, defaults to server.key

    --log

    Path to the log file.

  2. key_talker - this reads the key from the command line and sends it to the listener via secured connection.

    key_talker [--host host] [--port port] [--certs directory] [--cert-file file] [--key-file file] [--ca-file file]

    Following is description of the options:

    --host

    Host or IP to which the encryption key should be sent.

    --port

    Port to which the encryption key should be sent.

    --certs

    Directory in which the listener expects the SSL certificates to initialize the secured connection for the key transfer. If not specified, it looks for the certificates in the current directory.

    --cert-file

    Certificate file name, defaults to client.crt

    --key-file

    Key file name, defaults to client.key

    --ca-file

    Certification authority (CA) file. It should contain the certificate (chain) to validate the server certificate of the listener. It may be needed if the listener's server certificate is self-signed. In that case, a possible solution is to transfer server.crt to the machine the talker is running on and make --ca-file point to it.

    --key

    The encryption key to be sent. If not specified, the standard input is used.

F.21.1. Example #

First, make sure you have the SSL certificates - see Section 18.9.5 how to create them.

Then set encryption_key_command in postgresql.conf so it points to key_listener:

encryption_key_command = '/usr/local/bin/key_listener --certs /home/postgres/certs'

Then initiate the PostgreSQL server startup (typically using the pg_ctl command) and while the server is starting, use key_talker application in another console (which can in fact be on another host) to send the encryption key to the key listener:

key_talker --certs /home/postgres/certs --key 3a8455151d1e8fcd5d308667ddc43086

Once the key listener receives the key, it prints it out to its standard output so that the PostgreSQL server can read it and finish the startup.

Please note that key_talker checks that the certificate it receives from key_listener is issued for the IP address the listener is bound to. Thus you might need to specify the IP address using the -addext option of the openssl req command. For example:

openssl req -x509 -newkey rsa:2048 -addext subjectAltName=IP:192.168.0.10 \
  -keyout server.key -nodes -out server.crt -subj "/CN=dbhost.yourdomain.com" -sha256 -days 365