Create certificates

Create self-signed certificates to install on a Redis Enterprise cluster.

When you first install Redis Enterprise Software, self-signed certificates are created to enable encryption for Redis Enterprise endpoints. 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

% 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

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

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

Server certificate guidelines

Server certificates support clusters.

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

Use the cluster's fully qualified domain name (FQDN) as the certificate Common Name (CN).
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)

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>

The Extended Key Usage attribute should be set to TLS Web Client Authentication and TLS Web Server Authentication.
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:

The Extended Key Usage attribute should be set to TLS Web Client Authentication.
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.