Using Secure Sockets Layer (SSL) Connections v6.2
Publication server and subscription server connections to Postgres publication databases, Postgres subscription databases, and Postgres primary nodes can be accomplished using secure sockets layer (SSL) connectivity.
xDB Replication Server does not support SSL connections to Oracle and SQL Server databases used within any xDB replication system.
For a single-master replication system, the following connections can be made to Postgres databases enabled with SSL:
- Publication server connection to the publication database and to the subscription databases.
- Subscription server connection to the subscription databases.
- Migration Toolkit connection to the publication and subscription databases.
For a multi-master replication system, the following connections can be made to Postgres databases enabled with SSL:
- Publication server connection to the primary definition node and the non-MDN nodes.
- Migration Toolkit connection to the primary definition node and the non-MDN nodes.
Note
SSL connections are not used from the xDB Replication Console or the xDB Replication Server Command Line Interface. The xDB user interfaces communicate with the publication server and subscription server, which in turn connect to the publication/subscription databases or primary nodes.
Note
The Migration Toolkit connection using SSL occurs within the context of the publication server and subscription server SSL connections. Therefore, there are no separate steps that you need to perform for the Migration Toolkit SSL connection.
Using SSL requires various prerequisite configuration steps performed on the database servers involved with the SSL connections as well as on the Java truststore and keystore on the hosts running the publication server and subscription server.
The Java truststore is the file containing the Certificate Authority (CA) certificates with which the Java client (the publication server and subscription server) uses to verify the authenticity of the server to which it is initiating an SSL connection.
The Java keystore is the file containing private and public keys and their corresponding certificates. The keystore is required for client authentication to the server, which is used for xDB Replication Server SSL connections.
The following is material to which you can refer to for guidance in setting up the SSL connections:
- See the section on secure TCP connections with SSL in Chapter 17 Server Setup and Operation in the PostgreSQL Core Documentation located at:
for information on setting up SSL connectivity to Postgres database servers.
- For information on JDBC client connectivity using SSL see the section on configuring the client in Chapter 4 Using SSL in the The PostgreSQL JDBC Interface (https://jdbc.postgresql.org/documentation/94/ssl.html).
The following sections provide additional information for the configuration steps of using SSL with the xDB Replication Server.
- Configuring SSL on a Postgres database server (Section Configuring SSL on a Postgres Database Server)
- Configuring SSL on a JDBC client for the publication and subscription servers (Section Configuring SSL for the Publication Server and Subscription Server)
- Requesting SSL connection to the xDB Replication Server databases (Section Requesting SSL Connection to the xDB Replication Server Databases)
Configuring SSL on a Postgres Database Server
This section provides an example of configuring SSL on a Postgres database server to demonstrate the use of SSL with xDB Replication Server. A self-signed certificate is used for this purpose.
Step 1: Create the certificate signing request (CSR).
In the following example the generated certificate signing request file is server.csr
. The private key is generated as file server.key.
Note
When creating the certificate, the value specified for the common name field (designated as CN=enterprisedb in this example) must be the database user name that is specified in the User field of the Add Database or Update Database dialog box used when defining the publication database (see Adding a Publication Database), subscription database (see Adding a Subscription Database), or primary nodes (see Adding the Primary definition node) and Creating Additional Primary nodes).
Alternatively, user name maps can be used as defined in the pg_ident.conf
file to permit more flexibility for the common name and database user name. Steps 8 and 9 describe the use of user name maps.
Step 2: Generate the self-signed certificate.
The following generates a self-signed certificate to file server.crt
using the certificate signing request file, server.csr
, and the private key, server.key
, as input.
Step 3: Make a copy of the server certificate (server.crt
) to be used as the root Certificate Authority (CA) file (root.crt
).
Step 4: Delete the now redundant certificate signing request (server.csr
).
Step 5: Move or copy the certificate and private key files to the Postgres database server data directory, POSTGRES_INSTALL_HOME/data
.
Step 6: Set the file ownership and permissions on the certificate files and private key file.
Set the ownership to the operating system account that owns the data subdirectory of the Postgres database server, which is either enterprisedb
or postgres
depending upon the chosen installation mode (Oracle compatible or PostgreSQL compatible) when you installed your Postgres database server.
Step 7: In the postgresql.conf
file, make the following modifications.
Step 8: Modify the pg_hba.conf
file to enable SSL usage on the desired publication, subscription, or primary node databases.
In the pg_hba.conf
file, the hostssl
type indicates the entry is used to validate SSL connection attempts from the client (the publication server and the subscription server).
The authentication method is set to cert with the option clientcert=1 in order to require an SSL certificate from the client against which authentication is performed using the common name of the certificate (enterprisedb in this example).
The map=sslusers
option specifies that a mapping named sslusers
defined in the pg_ident.conf
file is to be used for authentication. This mapping allows a connection to the database if the common name from the certificate and the database user name attempting the connection match the SYSTEM-USERNAME/PG-USERNAME
pair listed in the pg_ident.conf
file.
The following is an example of the settings in the pg_hba.conf
file if the publication and subscription databases (edb and subnode) must use SSL connections.
Step 9: The following shows the user name maps in the pg_ident.conf file related to the pg_hba.conf
file by the map=sslusers
option. These user name maps permit you to specify database user names pubuser, subuser, MMRuser, or enterprisedb in the User field of the Add Database or Update Database dialog box when adding the publication, subscription, or primary node databases in the xDB Replication Console.
In other words, these are the permitted set of database user names that can be used by the publication server and subscription server to connect to the publication, subscription, or primary node databases.
Step 10: Restart the Postgres database server after you have made the changes to the Postgres configuration files.
Configuring SSL for the Publication Server and Subscription Server
After you have configured SSL on the Postgres database server, the following steps provide an example of generating a certificate and keystore file for the publication server and subscription server (the JDBC clients).
Before you begin, configure the client for SSL with trigger mode.
If you are using PostgreSQL, on the SSL-enabled Postgres database server:
Make the following client/cert files available on the publication/subscription server using an SSL connection:
postgresql.crt
postgresql.pk8
root.crt
In our example, we use the copy of this self-signed certificate and key generated for the database server on the client side.
The default location of these files is
{user.home}/.postgresql(e.g/var/lib/edb/.postgresql/)
. The file location can be overridden using SSL connection parameters or Postgres SSL environmental variables, see Setting Non-default Paths using Environment Variables for more information.Note
If you used the Linux interactive installer, and set the operating system username as:
postgres
, your{user.home}
path is/var/lib/pgsql/
enterprisedb
, your{user.home}
path is/var/lib/edb/
, which is the same path created from an RPM installation.
Copy and rename the files:
Note
This completes the SSL configuration for the PostgreSQL publication server and subscription server.
If you are using EDB Postgres Advanced Server, on the SSL-enabled Postgres database server:
Make the following client/cert files available on the publication/subscription server using an SSL connection:
xdb.keystore
xdb_pkcs.p12
Step 1: Using files server.crt
and server.key located under the Postgres database server data subdirectory, create copies of these files and move them to the host where the publication server and subscription server are running.
For this example, assume file xdb.crt
is a copy of server.crt
and xdb.key
is a copy of server.key
.
Step 2: Create a copy of xdb.crt
.
Step 3: Create a Distinguished Encoding Rules (DER) format of file xdb_root.crt
. The generated DER
format of this file is xdb_root.crt.der
. The DER
format of the file is required for the keytool program in the next step.
Step 4: Use the keytool program to create a keystore file (xdb.keystore
) using xdb_root.crt.der
as the input. This process adds the certificate of the Postgres database server to the keystore file.
The keytool program can be found under the bin subdirectory of the Java Runtime Environment installation.
You will be prompted for a new password. Save this password for the next step.
Step 5: Generate the encrypted form of the new password specified in the preceding step.
The encrypted password must be specified with the sslTrustStorePassword
configuration option of the publication server configuration file for publication server SSL connections and the subscription server configuration file for subscription server SSL connections. (See Publication and Subscription Server Configuration Options for information on the publication server and subscription server configuration files.)
Encrypt the password using the xDB Replication Server CLI encrypt command. The following example shows this process encrypting the password contained in file infile.
Step 6: Create a PKCS #12
format of the keystore file (xdb_pkcs.p12
) using files xdb.crt
and xdb.key
as input.
You will be prompted for a new password. Save this password for the next step.
Step 7: Generate the encrypted form of the new password specified in the preceding step.
The encrypted password must be specified with the sslKeyStorePassword configuration option of the publication server configuration file for publication server SSL connections and the subscription server configuration file for subscription server SSL connections.
Encrypt the password using the xDB Replication Server CLI encrypt command.
Step 8: Copy files xdb.keystore
and xdb_pkcs.p12
to a directory location where they are to be accessed by the publication server and subscription server.
Step 9: In the publication server and subscription server configuration files, set the location of file xdb.keystore
with the sslTrustStore
option and the location of file xdb_pkcs.p12
with the sslKeyStore
option.
The following shows the SSL configuration options set for the files generated in this example.
The encrypted sslTrustStorePassword
is obtained from Step 5 after being specified for the keytool program in Step 4.
The encrypted sslKeyStorePassword
is obtained from Step 7 after being specified for the openssl pkcs12 program in Step 6.
Section Summary of SSL Configuration Options contains a summary of the publication server and subscription server configuration options for SSL connections.
Step 10: Restart the publication and subscription servers.
Configuring publication/subscription server in case of WAL stream changeset logging
In the case of WAL stream changeset logging, while adding a publication or a subscription database that accepts only ssl connection, xDB validates if the database server is configured for logical replication using libpq
connection.
Note
Ownership depends on the Replication Server service account user. If you have installed Replication Server using the native packages from the EDB repository, the default account user is enterprisedb so ownership needs be given to the enterprisedb user.
For the SSL connection, libpq
must have the certificates and key as given in the following table along with the client certs and key you set up for trigger mode. The default directory is ${user.home}/.postgresql
.
Note
If you are using EDB Postgres Advanced Server, you need to add and configure the following files, in addition to adding and configuring the xdb.keystore
and xdb_pkcs
files, which you added and configured in an earlier step.
If you are using PostgreSQL, you need to add and configure the following files, in addition to adding and configuring postgresql.pk8
, which you added and configured in an earlier step.
Table 7-1: libpq/Client SSL File Usage
File Name | Contents | Description |
~/.postgresql/postgresql.crt | Client certificate | Requested by the server. |
~/.postgresql/postgresql.key | Client private key | Proves that the client certificate is sent by the owner. However, does not indicate that the certificate owner is trustworthy. |
~/.postgresql/root.crt | Trusted certificate authorities (CA) | Checks that the server certificate is signed by a trusted certificate authority. |
Make sure that the name of the certificates and key is same as given in the above table.
Execute the following commands to change the permission of the certificates in ${user.home}/.postgresql
.
To setup different source and target database types (for example, source database =POSTGRESQL
and target database =enterprisedb
) follow the steps below:
Generate the certificate for
POSTGRESQL
database and follow the table 7-1 for placing certificate files in the default directory.Copy these certificates in EDB Postgres Advanced Server data directory.
Execute the following commands to change the permissions of the certificates in the EDB Postgres Advanced Server data directory.
Using different databases for the source and target
Follow these steps if you are using different databases for the source and target; for example, if you are using PostgreSQL for your source database and EDB Postgres Advanced Server for your target database.
Note
The commands in this section assume CN=db user name
.
Generate the certificate for the PostgreSQL database. See Configuring SSL on a Postgres database server.
Configure SSL for Replication Server. See the steps for PostgreSQL in Configuring SSL for the publication server and subscription server.
Create the same user in EDB Postgres Advanced Server which is same as the CN value used to generate the certificate for the PostgreSQL database. For example if
CN=postgres
if specified as shown in following command then thepostgres
role should be created in EDB Postgres Advanced Server.Create the user:
If you specified
map=sslusers
for PostgreSQL and EDB Postgres Advanced Server inpg_hba.conf
, add the following topg_ident.conf
using the same user name for both PostgreSQL and EDB Postgres Advanced Server:Copy the certificates from the PostgreSQL data directory to the EDB Postgres Advanced Server data directory:
Restart the EDB Postgres Advanced Server service.
Change the permissions of the certificates in the EDB Postgres Advanced Server data directory.
Make the required configuration changes for EDB Postgres Advanced Server see Configuring SSL on a Postgres database server and restart the service:
Requesting SSL Connection to the xDB Replication Server Databases
Once SSL connectivity has been configured, a URL option must be supplied when configuring a single-master or multi-master replication system for those databases to which an SSL connection is intended to be used.
The SSL URL option informs Java to use SSL when the publication server or subscription server attempts to connect to an xDB Replication Server database (publication, subscription, or primary node database) on which the SSL URL option has been set to true.
The configuration steps where these options are specified are as follows:
- For using SSL connections in a single-master replication system, the URL options must be specified as shown in Section Adding a Publication Database for the publication database and in Section Adding a Subscription Database for the subscription databases.
- For using SSL connections in a multi-master replication system, the URL options must be specified as shown in Section Adding the Primary definition node for the primary definition node and in Section Creating Additional Primary nodes for the non-MDN nodes.
Earlier we created self-signed certificates for the database server by specifying the value of the CN field as the database user name (for example, postgres or enterprisedb, and so on). In this case, we use the “verify-ca” value for sslmode parameter to indicate the server certificate is validated against the CA. We do this because the hostname given in the command Add Database or Update Database could not be verified against CN value present certificate, which is the database user name.
For publication, subscription, and primary node databases, in the URL Options field of the Add Database or Update Database dialog box, enter the following:
ssl=true&sslmode=verify-ca
Note
When a server certificate is created with the hostname as the CN value there is no need to specify sslmode=verify-ca
.
You can specify the ssl=true&sslmode=verify-ca
URL option on the Add Database dialog box.
Note
If you no longer wish to use an SSL connection to an xDB Replication Server database, you must completely delete the ssl=true
text from the URL Options field of the Add Database or Update Database dialog box. Simply changing true to false does not have the effect of disabling the SSL option.
Setting Non-default Paths using Environment Variables
You can override the default paths of certificates and keys by setting the non-default paths in a terminal using the environment variables PGSSLKEY, PGSSLCERT, and PGSSLROOTCERT. You then need to export the paths in a terminal before running any Replication Server CLI command or launching the EPRS Replication Console. For example:
After setting and exporting the environment variables, from the same terminal, you may either run the Replication Server CLI command or launch the EPRS Replication Console.
Setting Non-default Paths using SSL Connection Parameters
Non-default paths of certificates and keys can be overridden using SSL connection parameters sslrootcert, sslcert, and sslkey. You need to specify these parameter values in urlOptions:
You set urlOptions using either the:
- Replication Server CLI using the addpubdb/addsubdb command
- EPRS Replication Console while adding the publication and subscription database
Summary of SSL Configuration Options
The following is a summary of the publication server and subscription server configuration options that are applicable to SSL connections.
sslTrustStoreType
The sslTrustStoreType option specifies the truststore format. Set this option to the Java truststore format of the client.
sslTrustStoreType=truststore_format
The default value for truststore_format is jks for the JKS truststore file format.
sslTrustStore
The xDB Replication Server uses the default Java truststore for SSL connectivity.
The typical default location of the truststore is in directory JAVA_HOME/jre/lib/security
or JAVA_HOME/lib/security
in a file named cacerts
. (JAVA_HOME
is the Java installation directory.)
Specify the full directory path to the truststore file with this option. sslTrustStore=truststore_file
sslTrustStorePassword
Encrypt the password for the Java system truststore using the xDB Replication Server CLI encrypt command (see Encrypting Passwords) and specify the encrypted password with the sslTrustStorePassword
option.
sslTrustStorePassword=encrypted_password
sslKeyStoreType
The sslKeyStoreType
option specifies the keystore format. Set this option to the Java keystore format of the client.
sslKeyStoreType=keystore_format
The default value for keystore_format is pkcs12 for the PKCS #12 keystore file format.
sslKeyStore
Specify the full directory path to the keystore file with this option.
sslKeyStore=keystore_file
sslKeyStorePassword
Encrypt the password for the Java system keystore using the xDB Replication Server CLI encrypt command (see Encrypting Passwords) and specify the encrypted password with the sslKeyStorePassword option.
sslKeyStorePassword=encrypted_password
- On this page
- Configuring SSL on a Postgres Database Server
- Configuring SSL for the Publication Server and Subscription Server
- Using different databases for the source and target
- Requesting SSL Connection to the xDB Replication Server Databases
- Setting Non-default Paths using Environment Variables
- Setting Non-default Paths using SSL Connection Parameters
- Summary of SSL Configuration Options