Understanding Redis Software Certificate Expiration Warnings and What to Do Next

Redis Software uses TLS certificates to secure key cluster components, including the Cluster Manager UI, REST API, database proxy endpoints, and some types of inter-node communication. When you see a certificate expiration warning, it is an early alert that one or more certificates are approaching expiry. It does not always mean traffic is already failing, but it does mean you should investigate and plan renewal before expiry causes TLS validation errors or service disruption.

This article helps you quickly:

• Interpret the warning and determine whether it is urgent.

• Identify which certificate is affected.

• Understand likely impact.

• Choose the next action by certificate type.

For full renewal and recovery procedures (including emergency steps if connections are already failing), use:

• Procedural runbook: Troubleshooting TLS Connection Failures Caused by Certificate Expiration

• Reference documentation:

  • Certificates overview

  • Create certificates

  • Update certificates

  • Monitor certificates

Quick Fix

Use this table to orient yourself before changing anything:

Prerequisites

Before making changes, ensure you have:

• Access to the Cluster Manager UI and/or REST API.

• Permissions to view and update certificates.

• The hostname / FQDN / endpoint that clients are using (UI URL, API URL, database endpoint, load balancer DNS, etc.).

• Access to certificate inspection tools, for example openssl from a machine that can reach the endpoints.

• A maintenance window if client trust, browser behavior, or replication can be affected.

• The procedural article handy: Troubleshooting TLS Connection Failures Caused by Certificate Expiration. PENDING LINK

Important: Always use supported methods (Cluster Manager UI, rladmin, or REST API) to update certificates. Do not manually overwrite files under /etc/opt/redislabs. Stage new certificates in a temporary directory (for example /tmp) and point the update commands at those files.

What the Warning May Refer To

Redis Software supports several certificate slots, each securing a different surface area. The main certificates that customers commonly manage are:

The “cluster certs about to expire” warning may be triggered by any one of these. In practice, many customer cases come from:

• UI/API certificates (cm, api),

• Client traffic certificate (proxy),

• Replication certificates (syncer) for Replica Of / Active‑Active, or

• Metrics exporter certificate (metrics_exporter) that was left on an old expiry date while others were renewed.

Internode and advanced certificates (overview only)

Redis Software also uses additional internal or advanced certificates that are not part of most day‑to‑day rotations, for example:

• ccs_internode_encryption and data_internode_encryption for control‑plane and data‑plane internode encryption,

• sso_issuer and sso_service for SAML SSO,

• Other internal CAs for mesh/gossip in some versions.

Key points:

• In many deployments, the default internode certificates are autogenerated and rotated automatically by Redis Software.

• If you enable customer-managed internode encryption (CPINE/DPINE) in newer Redis Software versions, you can upload and manage your own CA‑issued internode certs using the dedicated internode encryption documentation.

• If an expiry warning clearly points at internode encryption or SSO certs, follow:

  • Certificates overview, and

  • Internode encryption

Rather than treating them like standard CM/API/Proxy rotation.

Does It Affect Anything?

Before expiry

Before the notAfter time, Redis Software can continue to use the certificate. The warning is a proactive signal only:

• No immediate outage is expected.

• You should still plan your renewal before the expiry date to avoid last‑minute work and potential downtime.

• Alerts are often configured to fire N days (e.g., 45 days) before expiry, so the warning date may not match the certificate's actual expiry date.

After expiry

The effect depends on which certificate‌ expired and how strictly clients validate certificates:

• Proxy expired

  • TLS clients that validate dates or hostnames may start rejecting the connection.

  • You may see TLS handshake failures or “certificate has expired” errors in application logs.

• Cm / api expired

  • Browsers and API clients may show insecure/expired cert warnings or fail the handshake outright.

  • The UI or API might still be reachable if users bypass warnings, but this is not recommended.

• Syncer expired (Replica Of / Active‑Active)

  • Replica Of links or CRDB sync connections can fail TLS validation.

  • Replication may stall or remain disconnected until certificates and configuration are refreshed.

• metrics_exporter expired

  • Metrics scraping over HTTPS may fail (for example, Prometheus scrape errors).

  • Core data-plane traffic is usually unaffected, but the warning persists until renewed.

• Internode or other advanced certs expired

  • Can cause inter-node communication problems, node join/replace failures, SSO login issues, or cluster instability.

  • These certificates are more sensitive; always follow the specific documentation for internode encryption or SSO.

How to Identify Which Certificate Is Near Expiry

Step 1: Identify where the warning appears

Note where you see the warning or failure:

• Cluster Manager UI: Banner such as “Cluster certs about to expire”.

• Cluster logs/alerts: Explicit references to cm_cert, api_cert, proxy_cert, syncer_cert, metrics_exporter_cert, or other logical names.

• Client logs or monitoring: TLS/SSL handshake errors when connecting to database endpoints.

• Replica Of / Active‑Active errors: Sync status stuck, CRDB links disconnected, or TLS errors in syncer logs.

This tells you whether the problem is:

• Management plane (UI/API),

• Client-facing (proxy/metrics), or

• Replication (syncer / CRDB).

Step 2: Check Prometheus / certificate metrics

If you are using Prometheus or the built‑in metrics endpoints:

• For v1 metrics, use node_cert_expiration_seconds (seconds until expiry) per logical certificate name and node.

• For v2 metrics, use node_cert_expires_in_seconds for the same purpose.

See Monitor certificates for exact examples of these metrics and how to interpret them.

Use these metrics to quickly answer:

• Which logical_name (for example, cm, api, proxy, metrics_exporter, syncer) has the lowest remaining time.

• Whether the issue is cluster-wide or limited to specific nodes.

Step 3: Inspect the certificate directly

From a machine that can reach the endpoint, you can inspect the live certificate:

# Example: inspect a certificate file you have
openssl x509 -in <certificate.pem> -noout -enddate -subject

# Example: inspect a live HTTPS endpoint
# (replace host:port with your UI/API/load balancer endpoint)
openssl s_client -connect <host:port> -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate -subject

Compare:

• notAfter (expiry time) with what the UI or alerts are reporting.

• subject and Subject Alternative Names (SANs) with how clients and browsers actually connect (FQDN, VIP, load balancer DNS, etc.).

Step 4: Check for partial rotation

If behavior is inconsistent. For example:

• Some browsers warn, others do not.

• Some database endpoints show correct expiry, others show the old date.

• Replica Of or Active‑Active is failing, but client traffic is fine.

Then treat the cluster as being in a partial rotation state:

• Verify each relevant certificate slot (cm, api, proxy, syncer, metrics_exporter, and any enabled advanced slots) individually.

• Make sure all nodes show the same cert and expiry for that slot.

• Confirm that you have updated every certificate type that matters for your scenario, not just one (for example only proxy but not metrics_exporter).

What to Do Next (By Certificate Type)

1. Management plane: cm and api certificates

What they secure

• cm: Browser access to the Cluster Manager UI.

• api: Programmatic access to the REST API.

Impact if expired

• Browsers may show security warnings or refuse to connect depending on policy.

• API clients may fail TLS handshake or trust-chain validation.

Next actions

1. Decide whether you will use self-signed or CA‑signed certificates.

   • Self-signed: Use the built-in script to generate new certs, then update them cluster-wide.

   • CA‑signed: Generate CSRs, have them signed by your CA, and then upload the resulting certs.

2. Renew or replace certificates:

   • Generate/obtain new cm and api certificates (see Create certificates).

   • Stage the new cert/key files on one cluster node (for example, under /tmp).

   • Update them with rladmin or REST API, for example:

     rladmin cluster certificate set cm \
       certificate_file /tmp/cm_cert.pem \
       key_file /tmp/cm_key.pem
     
     rladmin cluster certificate set api \
       certificate_file /tmp/api_cert.pem \
       key_file /tmp/api_key.pem

   • Alternatively, use the Cluster Manager UI under Cluster > Security > Certificates if your version supports updating those slots there.

3. Validate:

   • Connect to the UI/API using the same hostname your users and tools use in production (for example, FQDN, VIP, load balancer DNS).

   • Ensure browsers and API clients see the expected issuer, subject/SANs, and expiry date.

2. Client traffic: proxy certificate

What it secures

• TLS connections from client applications to Redis databases (database endpoints, often via load balancers).

Impact if expired or mismatched

• Applications may see TLS handshake or verification errors (for example, “certificate has expired”, “hostname mismatch”, or trust-chain failures).

• Some clients might continue to connect if they ignore certificate validation, but this is not recommended.

Next actions

1. Determine whether you are using:

   • Self-signed proxy certificates generated by Redis Software, or

   • CA‑issued proxy certificates managed by your security/PKI team.

2. Renew or replace the certificate:

   • Generate / obtain the new proxy certificate and key.

   • Make sure the Common Name (CN) and SANs cover exactly how clients connect:

     • Cluster FQDN

     • VIP DNS

     • Load balancer DNS, if used

   • Upload the files to a temporary directory (for example /tmp) on a cluster node.

   • Update the cluster:

     rladmin cluster certificate set proxy \
       certificate_file /tmp/proxy_cert.pem \
       key_file /tmp/proxy_key.pem

3. Validate:

   • Restart or recycle clients if required by your environment so they pick up the new certificate.

   • Confirm that TLS handshake succeeds and that client trust stores trust the issuing CA (or the self‑signed cert if you use it directly).

Tip: If you also use Replica Of or Active‑Active, updating proxy on the source cluster may require immediate follow‑up steps described in the next section.

3. Replication: syncer certificate (Replica Of and Active‑Active)

syncer certificates secure TLS connections for:

• Replica Of databases.

• Active‑Active (CRDB) databases.

Failure or mismatch here usually shows up as:

• Replica Of links stuck in error state.

• Active‑Active sync failing or lagging with TLS-related errors.

3.1 Replica Of

Impact

• Replica Of sync can break when the source’s proxy certificate or syncer certificate is changed, but the replica still expects the old certificate or trusts the wrong CA.

• Until both sides are updated, Replica Of recovery may not be possible.

Next actions

1. Update the proxy (and, if used, syncer) certificate on the source cluster using UI, rladmin, or REST API as described above.

2. As soon as the source certificate is updated, update the Replica Of configuration for the destination database to use the new certificate/trust:

   • Use the Cluster Manager UI to edit the Replica Of database and update:

     • The endpoint,

     • TLS settings, and

     • Certificate / CA trust according to the Replica Of documentation.

3. Verify that Replica Of resumes syncing and that there are no recurring TLS errors in logs.

Important: Perform the configuration update on the replica immediately after rotating the certificate on the source. The longer the gap, the longer the replica remains disconnected.

3.2 Active‑Active (CRDB)

Impact

• Active‑Active participants may become unable to connect over TLS after you change proxy or syncer certificates.

• CRDB health reports may fail or show disconnected links until the configuration is refreshed.

Next actions

1. Update proxy and/or syncer certificates on one or more clusters participating in the Active‑Active database, using the supported UI, rladmin, or REST API flows.

2. For each affected Active‑Active database, refresh the CRDB configuration so all participants recognize the updated certificates:

   crdb-cli crdb update --crdb-guid <CRDB-GUID> --force
   

   • Run this once per Active‑Active database that resides on the clusters where you changed certificates.

   • Do not run other crdb-cli crdb update operations between the certificate change and this refresh.

3. Verify:

   • crdb-cli crdb health-report --crdb-guid <CRDB-GUID> shows healthy links.

   • There are no ongoing TLS errors for CRDB sync in logs.

Note: Perform the crdb-cli crdb update --force step as soon as possible after changing certificates. Between steps, new connections using the old certificate may be rejected by clusters that already trust only the new certificate.

4. Metrics exporter: metrics_exporter certificate

What it secures

• TLS connections from monitoring systems (for example, Prometheus) to the Redis Software metrics exporter.

Impact if expired

• Scrapes over HTTPS can fail, resulting in missing metrics and alerts.

• Core database traffic is not directly impacted, but you may lose observability.

• The “cluster certs about to expire” warning can remain even if cm, api, and proxy were already renewed, until metrics_exporter is also updated.

Next actions

1. Generate/obtain a new metrics_exporter certificate and key (self-signed or CA-signed).

2. Stage the files on a node and update:

   rladmin cluster certificate set metrics_exporter \
     certificate_file /tmp/metrics_exporter_cert.pem \
     key_file /tmp/metrics_exporter_key.pem
   

3. Validate:

   • Confirm your monitoring system can scrape the endpoint successfully.

   • Ensure the certificate matches the hostname the monitoring system uses to reach Redis.

5. LDAP and mTLS: ldap_client, mtls_trusted_ca

These certificates are optional and only relevant if you use:

• LDAP for user authentication (ldap_client), or

• Certificate-based authentication (mTLS) for the REST API (mtls_trusted_ca).

Impact if expired or misconfigured

• LDAP authentication can fail (users unable to log in if LDAP is required).

• API clients using mTLS can fail to authenticate or establish TLS.

Next actions

• Follow the LDAP and mTLS sections of the Security docs:

  • LDAP authentication

  • Certificate-based authentication (if applicable)

• Renew or replace the relevant certs following those flows, then validate authentication from affected clients.

6. Internode encryption certificates (customer‑managed)

If you have enabled customer-managed internode encryption (CPINE/DPINE) in Redis Software 8 or later, you may be managing your own CA-issued certificates for:

• Control-plane internode encryption,

• Data-plane internode encryption.

Impact if expired or inconsistent

• Node join/replace operations can fail.

• Inter-node TLS handshakes may break, causing cluster communication issues.

• In some configurations, Redis may fall back to self-signed internode certificates if customer certificates expire.

Next actions

• Use the internode encryption and customer-managed certificate documentation:

  • Internode encryption

  • Update certificates (for cluster certificate set internal and REST API PUT /v1/cluster/certificates flows)

• Verify that:

  • The same CA chain is present on all nodes.

  • Certificates are valid, not expired, and include full chains.

  • Any fallback or 5‑day window behaviors are understood and monitored.

Common Scenarios

Scenario 1: Browser warning accessing the Cluster Manager UI

Symptoms

• The browser shows an expired or untrusted certificate warning when accessing the UI URL.

• Application/database traffic appears unaffected.

Likely cause

• The cm certificate has expired or no longer matches the hostname used in the browser.

What to do

• Inspect the cm certificate’s expiry and subject/SANs.

• Generate or obtain a replacement cm certificate with:

  • Correct FQDNs that match the UI URL,

  • A full certificate chain if using a CA.

• Update it using the UI, rladmin cluster certificate set cm ..., or REST API.

• Reconnect using the production UI URL and confirm the warning is gone.

Scenario 2: Certificate expiry warning appears, but expiry date seems far in the future

Symptoms

• The UI displays “cluster certificates are about to expire in less than X days”.

• Manual inspection shows the key service certificates expiring at a later date.

Likely cause

• The alert threshold (for example, 45 days) has been reached.

• Or a different certificate (for example, metrics_exporter or another slot) is near expiry while proxy / cm / api are fine.

What to do

• Use metrics (node_cert_expiration_seconds / node_cert_expires_in_seconds) to find the certificate with the lowest remaining time.

• Check each logical certificate (including metrics_exporter) in the UI Certificates screen.

• Renew any remaining certificate types that are close to expiry.

Scenario 3: Replica Of stops syncing soon after certificate changes

Symptoms

• Replica Of link was previously healthy.

• After rotating a certificate on the source cluster, Replica Of database remains in error or keeps failing to reconnect.

Likely cause

• The source proxy or syncer certificate was changed, but the Replica Of configuration on the destination still expects the old certificate or trusts the wrong CA.

What to do

• Confirm the new proxy / syncer certificate is correctly installed on the source cluster.

• Immediately update the Replica Of configuration on the destination cluster to use the new certificate trust.

• Follow Replica Of documentation to ensure TLS settings and certificates align.

• Wait for the link to resynchronize and verify there are no ongoing TLS errors.

Scenario 4: Active‑Active sync fails after certificate rotation

Symptoms

• Active‑Active CRDB previously healthy.

• After proxy or syncer certificate changes, CRDB health-report shows failures or sync breaks.

Likely cause

• CRDB participants have mismatched views of the certificates or credentials used for TLS connections.

What to do

1. Ensure the updated certificates (and their CA chains) are installed on all relevant clusters.

2. For each affected CRDB, run:

   crdb-cli crdb update --crdb-guid <CRDB-GUID> --force

3. Confirm CRDB health with crdb-cli crdb health-report and monitor for remaining TLS errors.

Scenario 5: Warning persists after renewing the main certificates

Symptoms

• You renewed cm, api, and proxy with a new CA-signed or self-signed certificate.

• The UI still shows “cluster certs about to expire”.

• Metrics show one certificate type still expiring sooner than others.

Likely cause

• At least one other certificate slot, often metrics_exporter, still uses the old cert with the earlier expiry date.

What to do

• Check the Certificates screen and metrics for metrics_exporter and any other logical names near expiry.

• Renew the remaining certificate slot(s) using the same certificate or CA chain (if appropriate).

• After updating, confirm that metrics show consistent expiry dates across all relevant certificates and that the UI warning clears.

Troubleshooting Checklist

If you still see failures or warnings after renewal:

1. Hostname and SANs

   • Ensure the certificate’s subject/SANs match exactly how clients, browsers, and load balancers connect.

2. Full certificate chain

   • Confirm that the certificate includes the full chain (leaf, intermediate, and root) where required.

   • Check that client trust stores include the expected CA(s).

3. Mixed or partial state

   • Use metrics and the Certificates UI to ensure that all certificate slots (cm, api, proxy, syncer, metrics_exporter, and any advanced ones you use) are updated and that all nodes share the same certificate for each slot.

4. Replica Of / Active‑Active

   • For Replica Of: confirm the replica configuration was updated right after rotating the source certificates.

   • For Active‑Active: ensure you ran crdb-cli crdb update --crdb-guid <CRDB-GUID> --force after certificate rotation and that you did not run conflicting crdb-cli updates in between.

5. Internode encryption and advanced features

   • If symptoms suggest node join/replace issues, internal TLS handshake failures, or SSO problems, switch to:

     • Internode encryption, and

     • The relevant access control / SSO documentation,
       rather than continuing with generic steps.

If, after following these steps, you still see certificate-related errors or warnings, capture:

• Current certificate configuration (from the Certificates UI or API),

• Relevant logs, including TLS error messages, and

• Recent configuration changes,

and contact Redis Support with this information for deeper analysis.