Enabling Secure Sockets Layer (SSL) for the Replication Manager

Berkeley DB uses an OpenSSL software library to provide SSL support for the Replication Manager (see "Replication Manager Overview" in the Getting Started with Replicated Berkeley DB Applications guide). This enables secure communication among Replication Manager group members by preventing:
  • Data snooping during exchange of data between replication nodes

  • Spoofing in a replication group by means of certificate-based authentication

Note:

SSL support in the Replication Manager is not built by default on Windows operating system. On Linux it is built by default only when suitable OpenSSL libraries and headers are present on UNIX. Otherwise, –with-repmgr-ssl=yes with suitable values for LDFLAGS, LIBS and CFLAGS/CPPFLAGS are required to build it.

On UNIX, providing –with-repmgr-ssl=no as an argument to  configure, disables the build of SSL support for Replication Manager.

On Windows, removing the definition of HAVE_REPMGR_SSL_SUPPORT from db_config.h in build_windows, disables SSL.

Once built, SSL support in the Replication Manager is enabled by default. You can, however, disable this by setting the Replication Manager flag DB_REPMGR_CONF_DISABLE_SSL using DB_ENV->rep_set_config()  before starting the Replication Manager.

Features

  1. SSL support exists for both Linux and Windows operating systems. However, it is your responsibility to install and ensure availability of OpenSSL header files and libraries while building Berkeley DB. You can do that by following the instructions mentioned in OpenSSL Installation document.
    Note that you must use OpenSSL-library versions greater than or equal to 1.0.1 that includes thread support. Unless this condition is met, the build will fail.
  2. A replication node without SSL support cannot join a replication group with SSL and vice versa. For more information on building Berkeley DB with SSL support, see the following sections of the Oracle Berkeley DB Installation and Build Guide :
    • "Building Secure Sockets Layer (SSL) Support for the Replication Manager" in Chapter "Building Berkeley DB for Windows"of the Oracle Berkeley DB Installation and Build Guide

    • "--with-replication-ssl" in Chapter "Building Berkeley DB for UNIX/POSIX" of the Oracle Berkeley DB Installation and Build Guide

  3. Transport Layer Security (TLSv1.2) protocol is used along with ciphers with the following criteria:
    1. Ciphers should have a key length of 128 bits or more.
    2. Ciphers should not use Secure Hash Algorithm 1 (SHA1).
    3. Ciphers should not use Data Encryption Service (DES) and Triple Data Encryption Service (3DES).
  4. You are responsible for creating the certificates and their corresponding keys. The certificates and keys provided by you are used for authentication/verification as well as for establishing a secure SSL connection. Note that, all certificates must be in Privacy Enhanced Mail Computing (.pem) format. It is assumed that private keys and corresponding passwords will not be compromised.

    You can use the DB_ENV->repmgr_set_ssl_config() method for specifying the location of the certificates and keys. You use this method to set the value of the following SSL configuration options:

    • DB_REPMGR_SSL_CA_CERT

      Location of CA certificate or CA chain certificate for verification.

    • DB_REPMGR_SSL_CA_DIR

      Location of directory containing all CA /Intermediate CA certificates for verification.

    • DB_REPMGR_SSL_REPNODE_CERT

      Location of certificate presented by this node to peers for authentication.

    • DB_REPMGR_SSL_REPNODE_PRIVATE_KEY

      Location of Private Key corresponding to the RepNode certificate.

    • DB_REPMGR_SSL_REPNODE_KEY_PASSWD

      Password protecting the aforementioned Private Key.

    • DB_REPMGR_SSL_VERIFY_DEPTH

      Number of levels of verification allowed for peer certificate verification.

  5. The Replication Manager provides support for authentication of Certificate Authority (CA) signed certificates as well as of Intermediate CA signed certificates. You can specify the location of CA certificates required for the necessary authentication.
Limitations
  • The Replication Manager does not allow you to provide multiple files or directories for CA certificate lookup.

  • The Replication Manager does not support selective revocation of suspect certificates. In case you suspect that one or more certificates have been compromised, you have to restart the entire replication group with a new set of certificates.

  • The Replication Manager does not support automatic renegotiation of session keys after certain number of bytes are transferred or after certain amount of time has elapsed.