创建证书

创建自签名证书以安装在 Redis Enterprise 集群上。

Redis 企业软件

首次安装 Redis Enterprise Software 时，将创建自签名证书以为 Redis Enterprise 终端节点启用加密。这些证书将在一年 （365 天） 后过期，必须续订。

您可以通过将这些证书替换为新的自签名证书或将其替换为由证书颁发机构 （CA） 签名的证书来续订这些证书。

续订自签名证书

从 v6.2.18-70 开始，Redis Enterprise Software 包含一个用于生成自签名证书的脚本。

默认情况下，generate_self_signed_certs.shscript 位于/opt/redislabs/utils/.

在这里，您将了解如何使用此脚本生成新证书以及如何安装它们。

步骤 1：生成新证书

登录到托管集群主节点的计算机，然后运行以下命令：

% 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 Cluster Manager UI
    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 a Cluster Manager UI 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 Cluster Manager UI
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.

    $ openssl x509 -req -in <key-file-name>.csr -signkey <key-file-name>.pem -out <cert-name>.pem

    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 <cert-name> certificate_file \
   <cert-name>.pem key_file <key-file-name>.pem

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

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

RATE THIS PAGE
Back to top ↑