When you first install Redis Enterprise Software, self-signed certificates are created to encrypt internal traffic. These certificates expire after a year (365 days) and must be renewed.

You can renew these certificates by replacing them with new self-signed certificates or by replacing them with certificates signed by a certificate authority (CA).

Renew self-signed certificates

As of v6.2.18-70, Redis Enterprise Software includes a script to generate self-signed certificates.

By default, the generate_self_signed_certs.sh script is located in /opt/redislabs/utils/.

Here, you learn how to use this script to generate new certificates and how to install them.

Step 1: Generate new certificates

Sign in to the machine hosting the cluster’s master node and then run the following command:

% sudo -u redislabs /opt/redislabs/utils/generate_self_signed_certs.sh \
   -f "<DomainName1 DomainName2>" -d <Days> -t <Type>

where:

  • <DomainName1> is the fully qualified domain name (FQDN) of the cluster. (This is the name given to the cluster when first created.)

  • <DomainName2> is an optional FQDN for the cluster. Multiple domain names are allowed, separated by whitespace. Quotation marks ("") should enclose the full set of names.

  • <Days> is an integer specifying the number of days the certificate should be valid. We recommend against setting this longer than a year (365 days).

    <Days> is optional and defaults to 365.

  • <Type> is a string identifying the name of the certificate to generate.

    The following values are supported:

    Value Description
    api The REST API
    cm The admin console
    metrics The metrics exporter
    proxy The database endpoint
    syncer The synchronization process
    all Generates all certificates in a single operation

    Type is optional and defaults to all.

When you run the script, it either reports success ("Self signed cert generated successfully") or an error message. Use the error message to troubleshoot any issues.

The following example generates all self signed certificates for mycluster.example.com; these certificates expire one year after the command is run:

$ sudo -u redislabs /opt/redislabs/utils/generate_self_signed_certs.sh \
    -f "mycluster.example.com"`

Suppose you want to create an admin console certificate to support two clusters for a period of two years. The following example shows how:

$ sudo -u redislabs /opt/redislabs/utils/generate_self_signed_certs.sh \
    -f "mycluster.example.com anothercluster.example.com" -d 730 -t cm

Here, a certificate file and certificate key are generated to support the following domains:

mycluster.example.com
*.mycluster.example.com
anothercluster.example.com 
*.anothercluster.example.com

Step 2: Locate the new certificate files

When successful, the script generates two .PEM files for each generated certificate: a certificate file and a certificate key, each named after the type of certificate generated (see earlier table for individual certificate names.)

These files can be found in the /tmp directory.

$ ls -la /tmp/*.pem

Step 3: Set permissions

We recommend setting the permissions of your new certificate files to limit read and write access to the file owner and to set group and other user permissions to read access.

$ sudo chmod 644 /tmp/*.pem

Step 4: Replace existing certificates

You can use rladmin to replace the existing certificates with new certificates:

$ rladmin cluster certificate set <CertName> certificate_file \
   <CertFilename>.pem key_file <KeyFilename>.pem

The following values are supported for the <CertName> parameter:

Value Description
api The REST API
cm The admin console
metrics_exporter The metrics exporter
proxy The database endpoint
syncer The synchronization process

You can also use the REST API. To learn more, see Update certificates.

Create CA-signed certificates

You can use certificates signed by a certificate authority (CA).

For best results, use the following guidelines to create the certificates.

TLS certificate guidelines

When you create certificates signed by a certificate authority, you need to create server certificates and client certificates. The following provide guidelines that apply to both certificates and guidance for each certificate type.

Guidelines for server and client certificates

  1. Include the full certificate chain when creating certificate .PEM files for either server or client certificates.

  2. List (chain) certificates in the .PEM file in the following order:

    -----BEGIN CERTIFICATE-----    
Domain (leaf) certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate CA certificate
-----END CERTIFICATE----
-----BEGIN CERTIFICATE-----
Trusted Root CA certificate
-----END CERTIFICATE-----

Server certificate guidelines

Server certificates support clusters.

In addition to the general guidelines described earlier, the following guidelines apply to server certificates:

  1. Use the cluster’s fully qualified domain name (FQDN) as the certificate Common Name (CN).

  2. Set the following values according to the values specified by your security team or certificate authority:

    • Country Name (C)
    • State or Province Name (ST)
    • Locality Name (L)
    • Organization Name (O)
    • Organization Unit (OU)

  3. The Subject Alternative Name (SAN) should include the following values based on the FQDN:

    dns=<cluster-fqdn>
dns=*.<cluster-fqdn>
dns=internal.<cluster-fqdn>
dns=*.internal.<cluster-fqdn>

  4. The Extended Key Usage attribute should be set to TLS Web Client Authentication and TLS Web Server Authentication.

  5. We strongly recommend using a strong hash algorithm, such as SHA-256 or SHA-512.

    Individual operating systems might limit access to specific algorithms. For example, Ubuntu 20.04 limits access to SHA-1. In such cases, Redis Enterprise Software is limited to the features supported by the underlying operating system.

Client certificate guidelines

Client certificates support database connections.

In addition to the general guidelines described earlier, the following guidelines apply to client certificates:

  1. The Extended Key Usage attribute should be set to TLS Web Client Authentication.

  2. We strongly recommend using a strong hash algorithm, such as SHA-256 or SHA-512.

    Individual operating systems might limit access to specific algorithms. For example, Ubuntu 20.04 limits access to SHA-1. In such cases, Redis Enterprise Software is limited to the features supported by the underlying operating system.

Create certificates

The actual process of creating CA-signed certificates varies according to the CA. In addition, your security team may have custom instructions that you need to follow.

Here, we demonstrate the general process using OpenSSL. If your CA provides alternate tools, you should use those according to their instructions.

However you choose to create the certificates, be sure to incorporate the guidelines described earlier.

  1. Create a private key.

    $ openssl genrsa -out <key-file-name>.pem 2048

  2. Create a certificate signing request.

    $ openssl req -new -key <key-file-name>.pem -out \
   <key-file-name>.csr -config <csr-config-file>.cnf

    Important:  The .CNF file is a configuration file. Check with your security team or certificate authority for help creating a valid configuration file for your environment.

  3. Sign the private key using your certificate authority.

    The signing process varies for each organization and CA vendor. Consult your security team and certificate authority for specific instructions describing how to sign a certificate.

  4. Upload the certificate to your cluster.

    You can use rladmin to replace the existing certificates with new certificates:

    $ rladmin cluster certificate set <CertName> certificate_file \
   <CertFilename>.pem key_file <KeyFilename>.pem

    For a list of values supported by the <CertName> parameter, see the earlier table.

    You can also use the REST API. To learn more, see Update certificates.