{
  "id": "create-certificates",
  "title": "Create certificates",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/security/certificates/create-certificates/",
  "summary": "Create self-signed certificates to install on a Redis Enterprise cluster.",
  "content": "\nWhen 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.\n\nYou can renew these certificates by replacing them with new self-signed certificates or by replacing them with certificates signed by a [certificate authority](https://en.wikipedia.org/wiki/Certificate_authority) (CA).\n\n## Renew self-signed certificates\n\nAs of v6.2.18-70, Redis Enterprise Software includes a script to generate self-signed certificates.  \n\nBy default, the `generate_self_signed_certs.sh` script is located in `/opt/redislabs/utils/`.  \n\nHere, you learn how to use this script to generate new certificates and how to install them.\n\n### Step 1: Generate new certificates \n\nSign in to the machine hosting the cluster's master node and then run the following command:\n\n``` bash\n% sudo -u redislabs /opt/redislabs/utils/generate_self_signed_certs.sh \\\n   -f \"\u003cDomainName1 DomainName2\u003e\" -d \u003cDays\u003e -t \u003cType\u003e\n```\n\nwhere:\n\n- _\\\u003cDomainName1\u003e_ is the fully qualified domain name (FQDN) of the cluster.  (This is the name given to the cluster when first created.)\n- _\\\u003cDomainName2\u003e_ is an optional FQDN for the cluster.  Multiple domain names are allowed, separated by whitespace.  Quotation marks (`\"\"`) should enclose the full set of names.\n- _\\\u003cDays\u003e_ is an integer specifying the number of days the certificate should be valid.  We recommend against setting this longer than a year (365 days).\n\n    _\\\u003cDays\u003e_ is optional and defaults to `365`.\n\n- _\\\u003cType\u003e_ is a string identifying the name of the certificate to generate.  \n    \n    The following values are supported:\n\n    | Value | Description |\n    |-------|-------------|\n    | `api` | The REST API |\n    | `cm` | The Cluster Manager UI |\n    | `metrics` | The metrics exporter |\n    | `proxy` | The database endpoint |\n    | `syncer` | The synchronization process |\n    | `all` | Generates all certificates in a single operation |\n\n    _Type_ is optional and defaults to `all`.\n\nWhen 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.\n\nThe following example generates all self signed certificates for `mycluster.example.com`; these certificates expire one year after the command is run:\n\n``` bash\n$ sudo -u redislabs /opt/redislabs/utils/generate_self_signed_certs.sh \\\n    -f \"mycluster.example.com\"`\n```\n\nSuppose you want to create a Cluster Manager UI certificate to support two clusters for a period of two years.  The following example shows how:\n\n``` bash\n$ sudo -u redislabs /opt/redislabs/utils/generate_self_signed_certs.sh \\\n    -f \"mycluster.example.com anothercluster.example.com\" -d 730 -t cm\n```\n\nHere, a certificate file and certificate key are generated to support the following domains:\n\n``` text\nmycluster.example.com\n*.mycluster.example.com\nanothercluster.example.com \n*.anothercluster.example.com\n```\n\n### Step 2: Locate the new certificate files\n\nWhen 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.)\n\nThese files can be found in the `/tmp` directory.\n\n``` bash\n$ ls -la /tmp/*.pem\n```\n\n### Step 3: Set permissions\n\nWe 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.\n\n``` bash\n$ sudo chmod 644 /tmp/*.pem\n```\n\n### Step 4: Replace existing certificates {#replace-self-signed}\n\nYou can use `rladmin` to replace the existing certificates with new certificates:\n\n``` console\n$ rladmin cluster certificate set \u003cCertName\u003e certificate_file \\\n   \u003cCertFilename\u003e.pem key_file \u003cKeyFilename\u003e.pem\n```\n\nThe following values are supported for the _\\\u003cCertName\u003e_ parameter:\n\n| Value | Description |\n|-------|-------------|\n| `api` | The REST API |\n| `cm` | The Cluster Manager UI |\n| `metrics_exporter` | The metrics exporter |\n| `proxy` | The database endpoint |\n| `syncer` | The synchronization process |\n\nYou can also use the REST API.  To learn more, see [Update certificates]().\n\n## Create CA-signed certificates\n\nYou can use certificates signed by a [certificate authority](https://en.wikipedia.org/wiki/Certificate_authority) (CA).  \n\nFor best results, use the following guidelines to create the certificates.\n\n### TLS certificate guidelines\n\nWhen 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. \n\n#### Guidelines for server and client certificates\n\n1.  Include the full [certificate chain](https://en.wikipedia.org/wiki/X.509#Certificate_chains_and_cross-certification) when creating certificate .PEM files for either server or client certificates.   \n\n1.  List (_chain_) certificates in the .PEM file in the following order:\n\n    ``` text    \n    -----BEGIN CERTIFICATE-----    \n    Domain (leaf) certificate\n    -----END CERTIFICATE-----\n    -----BEGIN CERTIFICATE-----\n    Intermediate CA certificate\n    -----END CERTIFICATE----\n    -----BEGIN CERTIFICATE-----\n    Trusted Root CA certificate\n    -----END CERTIFICATE-----\n    ```\n\n#### Server certificate guidelines\n\nServer certificates support clusters.  \n\nIn addition to the general guidelines described earlier, the following guidelines apply to server certificates:\n\n1.  Use the cluster's fully qualified domain name (FQDN) as the certificate Common Name (CN).\n\n1.  Set the following values according to the values specified by your security team or certificate authority:\n\n    - Country Name (C)\n    - State or Province Name (ST)\n    - Locality Name (L)\n    - Organization Name (O)\n    - Organization Unit  (OU)\n\n1.  The [Subject Alternative Name](https://en.wikipedia.org/wiki/Subject_Alternative_Name) (SAN) should include the following values based on the FQDN:\n\n    ``` text\n    dns=\u003ccluster-fqdn\u003e\n    dns=*.\u003ccluster-fqdn\u003e\n    dns=internal.\u003ccluster-fqdn\u003e\n    dns=*.internal.\u003ccluster-fqdn\u003e\n    ```\n\n1.  The Extended Key Usage attribute should be set to `TLS Web Client Authentication` and `TLS Web Server Authentication`.\n\n1.  We strongly recommend using a strong hash algorithm, such as \u003cnobr\u003eSHA-256\u003c/nobr\u003e or \u003cnobr\u003eSHA-512\u003c/nobr\u003e.\n\n    Individual operating systems might limit access to specific algorithms.  For example, Ubuntu 20.04 [limits  access](https://manpages.ubuntu.com/manpages/focal/man7/crypto-policies.7.html) to \u003cnobr\u003eSHA-1\u003c/nobr\u003e.  In such cases, Redis Enterprise Software is limited to the features supported by the underlying operating system.\n\n\n#### Client certificate guidelines\n\nClient certificates support database connections.  \n\nIn addition to the general guidelines described earlier, the following guidelines apply to client certificates:\n\n1.  The Extended Key Usage attribute should be set to `TLS Web Client Authentication`.\n\n1.  We strongly recommend using a strong hash algorithm, such as \u003cnobr\u003eSHA-256\u003c/nobr\u003e or \u003cnobr\u003eSHA-512\u003c/nobr\u003e.\n\n    Individual operating systems might limit access to specific algorithms.  For example, Ubuntu 20.04 [limits  access](https://manpages.ubuntu.com/manpages/focal/man7/crypto-policies.7.html) to \u003cnobr\u003eSHA-1\u003c/nobr\u003e.  In such cases, Redis Enterprise Software is limited to the features supported by the underlying operating system.\n\n### Create certificates\n\nThe 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. \n\nHere, we demonstrate the general process using OpenSSL.  If your CA provides alternate tools, you should use those according to their instructions. \n\nHowever you choose to create the certificates, be sure to incorporate the guidelines described earlier.\n\n1.  Create a private key.\n\n    ``` bash\n    $ openssl genrsa -out \u003ckey-file-name\u003e.pem 2048\n    ```\n\n1.  Create a certificate signing request.\n\n    ``` bash\n    $ openssl req -new -key \u003ckey-file-name\u003e.pem -out \\\n       \u003ckey-file-name\u003e.csr -config \u003ccsr-config-file\u003e.cnf\n    ```\n    _Important:\u0026nbsp;_ 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.\n\n3.  Sign the private key using your certificate authority.\n\n    ```sh\n    $ openssl x509 -req -in \u003ckey-file-name\u003e.csr -signkey \u003ckey-file-name\u003e.pem -out \u003ccert-name\u003e.pem\n    ```\n\n    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.\n\n4.  Upload the certificate to your cluster.\n\n    You can use [`rladmin`]() to replace the existing certificates with new certificates:\n\n    ``` console\n    $ rladmin cluster certificate set \u003ccert-name\u003e certificate_file \\\n       \u003ccert-name\u003e.pem key_file \u003ckey-file-name\u003e.pem\n    ```\n\n    For a list of values supported by the `\u003ccert-name\u003e` parameter, see the [earlier table](#replace-self-signed).\n\n    You can also use the REST API.  To learn more, see [Update certificates]().\n\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}